허원철의 개발 블로그

OAuth ...? JWT...! 본문

authentication

OAuth ...? JWT...!

허원철 2016. 12. 5. 08:20
이번글은 OAuth 부터 JWT 까지의 전반적인 내용에 대한 간략한 글입니다.


2007년 10월
OAuth1.0
 - 세션 고정 공격(Session Fixation Attack) 보안 결점 발견됨


2009년 06월
OAuth1.0a
 - User, Consumer, Service Provider
ex )
User : 트위터 사용자
Consumer : 트위터 단말 어플리케이션
Service Provider : 트위터 API 서비스
 - 인증프로세스 : 로그인 요청 -> 인증 서버를 통해 인증 -> 인증 토큰 전달 -> 성공

※ 인증 토큰을 가짐으로서의 장점..?
1. Consumer 가 id/pw를 가지지 않아도 됨
2. 권한 제어 가능
3. 사용자가 인증서비스에서 권한 취소도 가능
4. 패스워드 변경 시에도 인증 토큰과는 무관(계속 유효한 토큰을 가짐)



2010년 04월
OAuth2.0
(2-legged, 3-legged 등)
 - OAuth1.0a 와 동일한 개념인 인증 토큰을 사용
1. 장점
 ① 간단해졌다.
 ② 여러가지 인증 방법 지원
 ③ 대형 서비스로의 확장성 지원
 ④ 불려지는 용어 변경
  - Resource Owner : 사용자
  - Resource Server : API 서버
  - Authorization Server : 인증 서버(API 서버와 같을 수 있음)
  - Client : 써드파티 어플리케이션

2. Client 종류
 - 2가지로 분류됨
 ① Confidential Client : 인증서(인증 토큰)를 안전하게 보관할 수 있는 경우 
 ② Public Client :인증서(인증 토큰)를 안전하게 보관할 수 없는 경우(redirect_uri 이용)

3. 인증방식
 - 시나리오 x Client = 4가지 경우 존재
 - But, Authorization Code Grant와 Implicit Grant 이외에는 3-legged OAuth 방법 아니기 때문에 Open API 으로 거의 사용되지 않음

 ① Authorization Code Grant
 - 웹 서버에서 API를 호출하는 등의 시나리오에서 Confidential Client가 사용하는 방식이다. 서버사이드 코드가 필요한 인증 방식이며 인증 과정에서 client_secret 이 필요하다.
로그인시에 페이지 URL에 response_type=code 라고 넘긴다.

 ② Implicit Grant
 - token과 scope에 대한 스펙 등은 다르지만 OAuth 1.0a과 가장 비슷한 인증방식이다. Public Client인 브라우저 기반의 어플리케이션(Javascript application)이나 모바일 어플리케이션에서 이 방식을 사용하면 된다. Client 증명서를 사용할 필요가 없으며 실제로 OAuth 2.0에서 가장 많이 사용되는 방식이다.
로그인시에 페이지 URL에 response_type=token 라고 넘긴다.

★ OAuth2.0은 기본적으로 Bearer 토큰(암호화하지 않은 그냥 토큰)을 주고받는 것으로 인증을 한다. HTTPS 에 의존.

★ Refresh Token - 토큰 만료기간을 짧게 해서 노출 위험을 줄임(access token 갱신)

4. 단점 
 ① 클라이언트 구분 어려워짐
 ② ssh 에 의존
 ③ 토큰 관리를 해야함
 ④ 너무 많은 방식의 인증



2015년 03월

JWT (Json Web Token)
- OAuth 는 일반적인 스트링 형태. But, JWT는 JSON Claim 기반 방식

※ Claim 기반이란?
 - 사용자의 추가 정보를 토큰에 담음

1. 장점
 ① 작은 데이터이다.
 ② 권한정보를 토큰이 가지고 있어 DB를 액세스할 필요 없다.

2. 구조
 - 세가지 구분을 . 으로 나눔
 ① Header (헤더)
 ② Payload (유효 탑재량)
 ③ Signature (서명)
 - JWT : {Header}.{Payload}.{Signature}

3. Header
 - ex ) {"alg" : "HS256", "typ" : "JWT"}
 - Header는 일반적으로 JWT인 토큰의 유형과 HMAC SHA256 또는 RSA와 같이 사용되는 해시 알고리즘으로 구성됩니다.
 - Base64Url로 인코딩 됨

4. Payload
 - ex ) { "sub": "1234567890", "name": "John Doe", "admin": true }
 - Claims이 들어있는 엔티티와 추가 메타 데이터
 - Base64Url로 인코딩 됨

5. Signature
 - 인코딩된 Header, 인코딩된 Payload, 헤더에 지정된 알고리즘의 secret을 가지고 있어야 하고 서명을 해야한다.



참고
- OAuth2.0

- JWT


저작자표시

'authentication' 카테고리의 다른 글

auth0 JWT 활용하기  (417) 2017.02.12
'authentication' Related Articles more
Comments