www.notion.so/OAuth-1ac11441fca1492191283ef70c589b89
OAuth
OAuth
www.notion.so
OAuth
- OAuth
아이디나 암호가 노출되지 않고 api의 접근을 위임하는 방식
인증과 인가를 사용하는 방식
써드파티에 아이디 비밀번호를 넘기는건 위험하므로 api 토큰을 써드파티가 사용하게함
써드파티 어플리케이션이 api 토큰으로 api 서비스 정보를 요청하고 받아올수 있음
Request Token 의 요청과 발급이 이루어지고
사용자 인증 페이지 호출
사용자 로그인 완료
사용자의 권한 요청 및 수락
Access Token 발급
Access Token 을 이용해 서비스 정보를 요청
2. OAuth 1 과 2 의 차이점
2는 SSL을 사용함
2는 Client에서 암호화를 위한 코드를 삽입할 필요가 없음 (SHA1등)
1은 인증을 얻기 위해 web 환경만 지원
2는 web 말고 다른 환경도 지원함.
1은 보안토큰이 2개 사용되고 2는 하나만 사용됨
3. OAUTH2 기준 구현 방식이 뭐가 있고 어떤 시나리오에 적합한가
시나리오
적합한 시나리오는 서드파티 나 다른 어플리케이션 , 모바일 어플리케이션 또는
웹의 SPA 방식에서 아이디와 비밀번호를 노출하지않고 토큰으로 리소스를 가져오는 것
구현 방식
security에서 oauth 설정
인증 서버 클래스 설정
인가 서버 클래스 설정
(자세하게 추가 필요)
4. OAUTH2 기반으로 JWT 라는 게 있는데 이거는 뭐고 어떤 경우에 좋고 어떤 고려사항이 있는가
JWT 란
토큰을 JSON 방식으로 만들고 모든 정보 ( 토큰의 기본 정보 , 유저 정보, 토큰이 검증됐다는것을 증명해주는 시그니쳐 정보 ) 를 가지고 있고 헤더나 url에 넣어서 전달이 가능함.
총 3가지 부분으로 나뉘어져 있는데 . 으로 그것을 구분하며
첫번째 헤더 부분 은 토큰의 타입과 해싱 알고리즘이 등록 되어있고
두번째 내용 (페이로드 ) 부분은 등록된 클레임 , 공개 클레임 , 비공개 클레임이 등록되어있습니다.
등록된 클레임 은 서비스에서 필요한 정보들이 아닌 토큰에 대한 정보들을 담기위하여 이름이 이미 정해진 클레임들입니다.
예) 토큰발급자 iss , 토큰 제목 sub , 토큰 대상자 aud 토큰 만료시간 exp 등
공개 클레임은 충돌이 방지된 이름을 가지고 있어야 하므로 클레임 이름을 URI 형식으로 짓습니다.
예) "https://xxxx.xxx/aa/aa" : true
비공개 클레임은 클라이언트와 서버의 협의하에 사용되는 클레임 이름들입니다.
공개 클레임과는 달리 이름이 중복되어 충돌이 될수 있습니다.
예) "username" : "aaaa"
payload 예)
{
"iss": "velopert.com",
"exp": "1485270000000",
"https://velopert.com/jwt_claims/is_admin": true,
"userId": "11028373727102",
"username": "velopert"
}
세번째 부분은 시그니쳐 부분입니다.
이 시그니쳐 부분은 헤더의 base64 인코딩 값 정보의 base64 인코딩 값을 합친 후 주어진 비밀키로 해쉬를 하여 생성.
JWT의 장점
jwt 발급 후 토큰 검증만 하면 되기 때문에 추가 저장소가 필요 없음
토큰 기반으로 하는 다른 인증 시스템에 접근이 가능
JWT의 고려사항
토큰의 페이로드에 3종류의 클레임을 저장하기 때문에 토큰의 길이가 엄청나게 길어질경우
네트워크에 부하를 줄수가 있다.
페이로드 인코딩은 자체 암호화가 아니라 base64인코딩이므로 중간에 탈취되서 디코딩하면
데이터가 보인다. 시그니쳐는 비밀키로 sha 해싱하기 때문에 알수가 없음.
stateless 무상태이기 때문에 제어 (임의 삭제, 수정 등) 이 불가 하므로 토큰 만료시간을 꼭 넣어줘야한다.
토큰은 클라이언트 측에서 관리해야 하기 때문에, 토큰을 저장해야 한다.
5. OAUTH 토큰을 어떤 식으로 전달하고 보관하는 것이 보안에 안전한가.
- 요청 헤더나 바디에 넣어서 전달하는 방법은 빠르나 보안에 매우 취약하다.
- 헤더에 쿠키를 담아 보내는 방법은 1번 보다는 안전하다 마찬가지로 탈취되면 보안에 취약함
- 계정정보가 담기지 않았으므로 1번보다는 안전하지만 탈취된 쿠키를 이용해 http 요청을 보내면 서버의 세션 저장소가 쿠키의 탈취 여부를 알수없어 그대로 정보를 제공함
- 해결책은 https 를 사용해 쿠키를 읽을수 없게 하거나 세션에 유효시간을 넣어준다.
- 세션 저장소를 사용하므로 서버에 어느정도 부하가 생김
- 계정정보가 담기지 않았으므로 1번보다는 안전하지만 탈취된 쿠키를 이용해 http 요청을 보내면 서버의 세션 저장소가 쿠키의 탈취 여부를 알수없어 그대로 정보를 제공함
- JWT 방식
- 장점
- stateless 하므로 따로 저장소를 사용하지 않습니다.
- 확장성이 뛰어나므로 토큰기반의 다른 인증시스템에 접근이 가능합니다. ( facebook, google 등)
- 단점
- claims가 많을수록 jwt가 길어짐. 요청이 많아질수록 자원낭비 발생함.
- 중요한 정보를 payload에 넣을수 없음. base64로 인코딩 되어있기때문에 손쉽게 디코딩해서 정보를 볼수가 있음.
- jwt 역시 탈취되면 유효기간이 지나기 전까지 정보가 탈취됨.
- AccessToken의 유효기간을 짧게하고 Refresh Token을 이용해 새롭게 인증을 요청시킬수 있게 변경해야함.
- 장점
6. Resource Server
실질적으로 요청이 들어오면 access_token을 확인 후 유효한지 체크 하고
요청에 알맞는 리소스를 response 해주는 서버
참조 출처
Oauth2의 암시적 허용
https://docs.microsoft.com/ko-kr/azure/active-directory/develop/v2-oauth2-implicit-grant-flow
JWT
JWT 고려사항
https://mangkyu.tistory.com/56
OAUTH 토큰 보안
'개발 > etc' 카테고리의 다른 글
| 네트워크 복습 1 (0) | 2020.08.14 |
|---|---|
| JUnit5 에서 parameter 사용하기 (0) | 2020.07.21 |
| Lombok (0) | 2020.07.19 |
| 어플리케이션 아키텍처와 객체지향 영상 후기 (0) | 2020.06.28 |
| blob (0) | 2020.04.30 |