OAuth 2.0

* OAuth 2.0 개요

OAuth는 인증 계층을 도입하여 클라이언트의 역할과 리소스 소유자의 역할을 분리한다. 

OAuth에서 클라이언트는 제어되는 리소스에 대한 액세스를 요청한다. 그럼 리소스 소유자가 요청의 검증을 직접 하는 것이 아닌, 클라이언트는 3rd party clients(OAuth)에게서 액세스 토큰(access token)을 발행받는다. 이 access token은 보호되고 있는 resource server로부터 보호되고 있는 리소스의 접근에 사용된다.  

OAuth에서 로그인 뿐만 아니라 데이터 접근 권한도 포함하고 있기 때문에, Auth는 Authentication(인증) 뿐만 아니라 Authorization(인가)도 포함하는 개념이다. 

Authentication vs Authorization 자세히 알아보기 

 

 

* OAuth 2.0 의 구성

- Resource Owner

보호된 리소스에 대한 액세스 권한을 부여할 수 있다. resoucre owner가 사람인 경우, 최종 사용자라고 한다.

- Resource Server

보호된 resource를 호스팅하는 서버이다. access-token을 사용하여 보호된 resource 요청을 수락하고 응답할 수 있다.  

- Client

OAuth를 이용하기 위해 resource 서버에 등록한 응용 프로그램

- Authorization Server

resource owner를 인증하고 권한을 얻은 뒤 client에 access-token을 발급하는 서버이다.

 

* OAuth 2.0 token 

1) Access Token

보호된 리소스에 접근하기 위해 필요한 자격증명으로서 사용자가 특정 앱에게 부여한 권환에 대한 정보가 담긴 문자열이다. 접근 토큰에는 접근할 수 있는 특정 scope들과 액세스 가능한 기간 등 사용자가 동의한 사항들에 대한 정보가 담겨 있다. 이 정보에 기반하여 권한 제공기관 및 데이터 제공기관은 앱의 요청에 응하게 된다.

2) Refresh Token

access token을 얻는데 사용되는 자격 증명이다. access token이 유효하지 않거나 만료될 때, 새 access token을 얻거나 동일하거나 더 좁은 scope의 추가 access token을 얻는데 사용된다. refresh token을 사용하면 인증 과정을 처음부터 다시 반복하지 않고 새로운 access token을 발급 받을 수 있다. 

 

* OAuth 2 인증종류

Authorization Code Grant

• 서버사이드 코드로 인증하는 방식
• 권한서버가 클라이언트와 리소스서버간의 중재역할
• Access Token을 바로 클라이언트로 전달하지 않아 잠재적 유출을 방지
• 로그인시에 페이지 URL에 response_type=code 라고 넘긴다

Implicit Grant

• token과 scope에 대한 스펙 등은 다르지만 OAuth 1.0a과 가장 비슷한 인증방식
• Public Client인 브라우저 기반의 어플리케이션(Javascript application)이나 모바일 어플리케이션에서 이 방식을 사용
• OAuth 2.0에서 가장 많이 사용되는 방식
• 권한코드 없이 바로 발급되서 보안에 취약
• 주로 Read only인 서비스에 사용
• 로그인시에 페이지 URL에 response_type=token 라고 넘긴다

Password Credentials Grant

• Client에 아이디/패스워드를 저장해 놓고 아이디/패스워드로 직접 access token을 받아오는 방식
• Client 를 믿을 수 없을 때에는 사용하기에 위험하기 때문에 API 서비스의 공식 어플리케이션이나 믿을 수 있는 Client에 한해서만 사용하는 것을 추천한다
• 로그인시에 API에 POST로 grant_type=password 라고 넘긴다

Client Credentials Grant

• 어플리케이션이 Confidential Client일 때 id와 secret을 가지고 인증하는 방식이다
• 로그인시에 API에 POST로 grant_type=client_credentials 라고 넘긴다.

 

* Client 등록

프로토콜을 시작하기 전, client는 authorization server에 등록되어야 한다. 

client를 등록할 때, client 개발자는 

• client type을 명시하여야 한다. 
• client redirection URI를 제공하여야 한다. 
• authorization server가 요구하는 다른 정보들(application name, website 등)을 포함하여야 한다. 

 

Client Types

OAuth는 인증서버와 안전하게 인증할 수 있는 ability를 기반으로, 2가지 client 타입을 정의한다.

1) confidential

자격 증명의 기밀성을 유지할 수 있는 client type(예: 클라이언트 자격 증명에 대한 액세스가 제한된 보안 서버에서 구현된 클라이언트). 또는 다른 수단을 사용하여 클라이언트 인증을 보호할 수 있는 클라이언트 

2) public

자격 증명의 기밀성을 유지할 수 없는 client type(예: 설치된 기본 응용 프로그램 또는 웹 브라우저 기반 응용 프로그램과 같이 리소스 소유자가 사용하는 장치에서 실행되는 client). 또는 다른 수단을 사용하여 클라이언트 인증을 보호할 수 없는 클라이언트 

authorization server의 보안 인증의 정의와 client 자격 증명의 허용 가능한 노출 수준에 따라서 나뉜다. 

 

Client Identifier

authorization server는 등록된 client에게 client identifier를 발급한다. 어플리케이션 식별자

예) 네이버라면 네이버 어플, 네이버 웹, 뭐 어떤 환경으로 client 등록했는지

 

 Client Secret 

Client ID(어플리케이션 식별자)에 대한 비밀번호

 

Autorhized redirect URIs 

유저가 성공적으로 애플리케이션에 인증을 마친 후, Authorization Servers는 해당 경로로 리디렉합니다.

 

 

* OAuth protocol flow

출처 - https://datatracker.ietf.org/doc/html/rfc6749#section-1.2

 

(A) 클라이언트가 resource owner에게 권한 부여를 요청한다. 이 요청은 위의 그림과 같이 바로 resource owner에게 요청될 수도 있고, authorization server에게 갈 수도 있다.

(B) resource owner는 client에게 권한을 부여한다. 

(C) client는 authorization server에게 부여받은 권한을 제시하고 access-token을 요청한다. 

(D) authorization server는 client를 인증하고 부여받은 권한을 확인하여, 유효하다면 access-token을 발급해준다.  

(E) client는 발급받은 access-token을 들고 resource server에게 가서 resource server가 보호하고 있는 resource를 요청한다.

(F) resource server는 access-token의 유효성을 검증한 뒤, 유효하다면 요청을 처리한다. 

 

+) 좀 더 자세한 flow

출처: https://woodcock.tistory.com/17 

 

1

User가 클라이언트의 로그인이 필요한 자원에 접근합니다.

2~3

- client_id, redirect_url, response_type, scope을 포함하여 사용자의 브라우저를 

Authorization Server에 리다이렉션 시킵니다.
이때 Authorization Server는 파라미터로 받은 client_id와 redirect_url이 사전에 등록된 정보와 일치하는지 검증합니다.
민감한 정보가 포함되니 일치하지 않는다면(검증 실패) 요청이 거절됩니다.

4~5

- 로그인 페이지를 열고 User에게 Client가 등록한 scope에 대한 정보 제공 동의 허용 여부를 나타냅니다.
ex) ~에서 사용자의 프로필 이미지, 사용자 이름에 접근 하려고 합니다.

6~12

- User가 동의하고 로그에 성공하면 Authorization Server는 Client에게 "Authorization code"를 발급합니다.
그리고 클라이언트는 Authorization code, client id, secret을 Authorization Server에 다시 전송합니다.

Authorization Server는 전달받은 데이터를 검증하고 "Access Token"을 Client에게 발급합니다.
이제 Access Token을 이용해서 Resource Server에 데이터를 요청하고 검증이 완료되면 Resource서버는 Client에게 scope 범위의 데이터를 응답합니다.

- refresh token을 이용

출처 - https://datatracker.ietf.org/doc/html/rfc6749#appendix-A.1

(A) ~ (E) 까지는 위의 상황과 같음

(F) invalid token error: 토큰이 expired 되었기 때문에 더이상 토큰이 유효하지 않게 되었다.

(G) client는 authorization server로 가서 refresh token을 주고 새로운 access token을 발급ㅍ요청한다. client 인증 요구사항은 클라이언트 타입과 인증 서버 정책에 근거한다 .

(H) authorization server는 client를 인증하고 refresh token의 유효성을 검증, 유효하다면 새로운 access token을 발급해준다. optionally, 새로운 refresh token을 발급할 떄도 있음

 

 

출처 - https://velog.io/@denmark-choco/OAuth-2

OAuth 2

https://datatracker.ietf.org/doc/html/rfc6749#section-1.4

rfc6749

https://woodcock.tistory.com/17