Oauth 2.0 (feat. Oauth 1.0)

Oauth 1.0

 

참고

https://medium.com/identity-beyond-borders/oauth-1-0-vs-oauth-2-0-e36f8924a835

https://oauth.net/core/1.0/

 

목적

Oauth 1.0의 목적은 Oauth 2.0의 목적과 같다.

- third-party application이 resource owner와 http service 간의 합의를 통해서. resource owner대신에 http service에 제한된 접근권한을 가질 수 있게 한다.

 

 

FLOW 그림

과정 설명

OAuth Authentication is done in three steps:

1. The Consumer obtains an unauthorized Request Token.
2. The User authorizes the Request Token.
3. The Consumer exchanges the Request Token for an Access Token.

번역 하자면

 

Oauth 1.0 인증 과정

1. consumer(client)가 인증 서버에서 미인증 토큰(request token)을 발급 받음
2. 사용자가 request token을 인증서버에서 인증받음 (Browser web UI 등에서 로그인과 같은 작업을 통해서 id, pw 와 함께 request token을 인증서버에 보내어 인증받음)
3. consumer(client)가 인증된 request token을 access token과 교환

 

Oauth 2.0과 차이

Oauth 2.0 에서는 없는 request token이 개념이 존재한다.
인증 과정에서 주고받는 데이터들이 Oauth 2.0에 비해 많고 복잡하다

 

 

Oauth 2.0

참고 : https://oauth.net/2/

 

목적

Oauth 1.0과 2.0의 목적은 같다. 

third-party application이 resource owner와 http service 간의 합의를 통해서. resource owner대신에 http service에 제한된 접근권한을 가질 수 있게 한다.

 

Flow 요약 그림

 

Access Token 이란?

• client(third-party application)가 resource server(http service)에 요청을 하기 위해 사용됨
• 정해진 형식은 없다. 서버마다 다양한 형식이 존재한다.
• bearer token 또는 sender-constrained token 이어야 한다.
  • bearer token : 무기명 토큰이다. 사용하는 client에게 아무의미 없는 문자열이다.
    (bearer token 설명 https://oauth.net/2/bearer-tokens/)
  • sender-constrained token : 말그대로 token을 send할 수 있는 client가 제한된 token이다.
    client는 access token을 사용하기 위해 private key을 소유하고 있어야 한다.
• Access token은 client에 의해 읽히거나 해석되지 말아야 한다.
• Access token은 client에게 user 식별자 등의 user 정보를 전달하지 않아야 한다.
• Access token은 resource server(위 http service provider)에게 요청을 위해서만 사용되어야 한다.
  ID Token이 resource server 요청을 위해 사용되면 안된다.
  ID Token 의 특징
  • user 정보 및 인증 정보를 담고 있음.
  • client가 읽을 수 있도록 의도됨
  • ID Token은 절대 Server API 로 보내져선 안된다.
    (Access token은 절대로 client에 위해 의미를 담고 있으면 안되는 것처럼)

 

Refresh token 이란?

• user와의 상호작용 없이 새로운 access token을 얻기 위해 사용한다.
• client가 기존에 허락된 권한 범위를 넘어선 접근을 허용하면 안된다.
• refresh token은 인증 서버에서 사용자의 개입 없이 짧은 수명의 액세스 토큰을 사용할 수 있도록 하기 위해 존재한다. (말이 조금 이상한데, 짧은 수명의 액세스 토큰을 사용하기 위해 refresh token이 존재한다. access token은 api 호출 시 마다 빈번히 사용된다. 탈취 된다고 하더라도 짧은 수명으로 인해 금방 만료됨. refresh token은 access token을 발급할 때만 가끔 사용하므로 비교적 탈취될 위험이 적다)

 

OAuth Scope 란?

• application(ex.third-party)이 사용자 계정에 접근하는 것을 제한하는 메커니즘이다.
• scope는 sevice별로 다르므로 따로 정의하지 않는다.
  (사용자 정보 scope / 신용카드 정보 scope 등 나누기 나름이다.)
• application이 접근 가능 scope들을 인증서버에 요청하고, 사용자 동의 화면에서 사용자가 허락한 scope로 access token의 접근이 제한된다.
• 범위를 벗어난 요청 scope에 대해 위와 같은 절차로 사용자 동의 후 접근 가능 scope를 수정할 수 있다.
  (하지만 중간에 scope 변경을 허락하는 서비스는 흔하지 않다고 나와있다)

 

Grant Types 란? (Access token을 얻기 위한 방법)

• Authorization Code : authorization code를 access token과 교환한다.
  1. user가 http service의 인증서버에 인증(로그인)한다.
  2. 인증 서버가 user를 authorization code와 함께 client로 redirct한다.
  3. client application은 authorization code를 url로부터 얻고 인증서버에 요청해 access token과 교환한다

• PKCE : Proof Key for Code Exchage
  Authorization Code 방식의 확장판이다.
  - code_verifier : 랜덤 생성 키
  - t(code_verifier) : transformed code_verifier. 변환된 키. code_challenge라고도 함
  - t_m : transformation method. 변환 방법. code_challenge_method라고도 함
  
  client가 Authorization Code 요청을 보내며 함께 보낸 t(code_verifier)을 인증서버가 기억한다.
  client가 Access token 요청 시 code_verifier을 보내고 인증서버는 t(code_verifier)와 비교한다
  
  mobile app과 같은 public client(아래 Client Types 설명 참고)을 위해 만들어 졌다.
  하지만 authorization code injection을 막는데 탁월 하여서 client secret 등의 client authentication을 사용한다고 해도 함께 사용하는 것을 권장한다.

• Client Credentials Grant
  말그대로 Client가 직접 증명을 진행하여 Access token을 받는 것이다.
  user 정보에 접근하기보다 자기 자신(client)과 관련된 자원에 접근할 때 사용한다
• Device Code
  browser가 없거나 input이 없는 등 제한된 device에서 사용된다.
  device code와 access code를 교환하는 방법이다.
  
  사용자와 기기의 상호작용이 불가능하여, 다른 기기를 이용하도록 하는 방법이다
  
  A. device client가 device client 식별자와 함께 인증 서버에 요청
  B. 인증 서버는 device code, user code, end-user verification URI 응답
  C. client는 end user에게 user code를 전달하고 인증 요청을 검토할 수 있도록 다른 기기로 verification URI 에 접속하도록한다.
  D. URI에서 접속 후 user는 user agent(web page)등으로 인증 서버에 인증하고(login 등) 인증 서버는 user가 user code를 입력하도록 안내한다. 인증 서버는 user code 확인 후 user에게 client 요청에 대한 동의를 받는다
  E. 위 과정이 진행 되는 동안 client는 장치 코드와 client식별자를 가지고 주기적으로 사용자가 인증 서버에 인증을 완료했는지 확인한다.
  F. 사용자 인증이 완료되면 인증 서버는 client에 access token을 응답한다.
  
  

• Refresh Token
  access token이 만료됐을 때 refresh token으로 access token을 재발급 받는다.
  user와 상호작용 하는 것 없이 유효한 access token을 계속해서 유지할 수 있다.
  refresh token을 발행하는 것은 인증서버 재량이다.
  인증서버가 refresh 토큰을 발행한다면 인증 과정 중 access token 발급 시 함께 발행된다

 

Client Types

• confidential : client secret 등을 사용해서 안전하게 인증 서버와 인증할 수 있는 application
  • client secret : application의 비밀번호라고 비유할 수 있다. 인증 서버와 application 서버만 앎.
• public : browser or mobile 등 등록하기 힘들고 client secret을 사용할 수 없는 application

 

Client Authentication

• Confidential client는 인증 서버에 요청할 때 인증이 필요하다
• “client password” 라는 client 인증 타입을 정의한다.
• client password를 http Authorization 헤더 또는 client_secret 파라미터에 포함한다.