인증(Authentication)과 권한 부여(Authorization)의 필요에 의해..
oauth의 목적은 access token을 발급하는 것.
Roles
OAuth는 4가지 역할을 정의한다. :
- Resource Owner (≒ User)
-
보호 자원protected resource에 접근하는 권한을 부여한다.
Resource Owner가 개인일 경우 이를 end-user 라고도 한다. - Client (≒ Application)
-
Reqource Owner를 대신하여 보호 자원에 접근을 요청하는 어플리케이션이다. - Resource Server (≒ Naver, Google, …)
-
보호 자원을 호스팅하는 서버로, Access Token 을 사용하여 보호 자원 요청을 수락하고 적절한 응답을 한다. 즉, 데이터를 가진 서버.
- Authorization Server
-
성공적으로
Resource Owner를 인증(authenticating)하고 authorization을 얻은 이후Client에게 Access Token 을 발급한다. 즉, 인증과 관련된 처리를 전담하는 서버.Authorization Server와Resource Server간의 상호 작용interaction은 이 스펙의 범위를 벗어난다.Authorization Server는Resource Server와 동일하거나 별도의 서버일 수 있다. 단일Authorization Server는 여러Resource Server에서 승인된 Access Token 을 발급할 수도 있다.
1. 등록
-
클라이언트가 리소스 서버를 이용하기 위해서는 리소스 서버의 승인을 사전에 받아놔야 함. → register
-
서비스마다 다르지만 공통적으로 아래 3개의 값을 공통적으로 받음
Client ID, Client Secret, Authorized redirect URIs
-
Client Secret은 외부에 노출되면 안됨.
-
Redirect URI: 리소스 서버가 권한을 부여하는 과정에서 인증 Code를 전달하기 위한 주소
-
2. 인증
-
Resource Owner가 Client에 접근
-
Client가 Resource Owner에게 "네이버의 어떠한 기능 활용하기 위해 동의가 필요합니다." 노출
-
네이버의 인증 버튼을 클릭하면 Resource Owner는 아래 구조와 같은 링크로 이동
https://resource.server/ ?client_id=1 &scope=B,C &redirect_uri=https://client/callback -
Resource Server가 Resource Owner의 로그인 상태 파악
-
로그인 되어 있을 경우 Client ID와 Redirect URI를 검증
-
Resource Owner에게 Client 에게 리소스를 제공해도 되는지 승인 요청
-
Resource Owner가 허용할 경우 Resource Server는 서버에 사용자와 리소스 허용 범위를 저장함
-
Resource Server가 ResourceOwner에게 redirect URI에 authorization code(임시 패스워드)를 붙혀서 전달
-
Resource Owner는 주어진 리다이렉트 주소로 이동하게 됨
-
Client는 authorization code를 획득함
-
Client는 Resource Server에 접근함
https://resource.server/token? grant_type=authorization_code& code=3& redirect_uri=https://client/callback& client_id=1& client_secret=2 -
Resource Server는 authorization code를 조회해서 어떤 Client ID인지 조회
-
Resource Server는 Client ID, Secret, Redirect URI, Code 모두 일치하는지 확인
-
Resource Server는 authorization code를 제거
-
Resource Server는 accessToken을 발급
-
Client에게 accessToken을 전달
-
Client는 accessToken을 서버에 저장함
Protocol Flow
@startuml
ditaa
+--------+ +---------------+
| |--(1)- Authorization Request ->| Resource |
| | | Owner |
| |<-(2)-- Authorization Grant ---| |
| | +---------------+
| |
| | +---------------+
| |--(3)-- Authorization Grant -->| Authorization |
| Client | | Server |
| |<-(4)----- Access Token -------| |
| | +---------------+
| |
| | +---------------+
| |--(5)----- Access Token ------>| Resource |
| | | Server |
| |<-(6)--- Protected Resource ---| |
+--------+ +---------------+
@enduml
-
클라이언트가 사용자의 데이터에 접근하기 위해 권한을 요청한다.
-
접근에 동의함을 증명하는 권한 부여 동의서(Authorization Grant)를 발급한다. REC 6749에서는 4가지 유형의 권한 부여 동의서를 정의한다.
-
권한 부여 동의서를 제출하여 접근 토큰을 요청한다. 접근 토큰은 사용자 데이터를 잠근 자물쇠를 여는 열쇠이다.
-
권한 부여 동의서를 확인하여 사용자가 동의한 데이터에 대한 정보가 담긴 접근 토큰을 제공한다.
-
접근 토큰을 제출하여 사용자 데이터를 요청한다.
-
사용자 데이터를 제공한다. 이때 앱이 제출한 접근 토큰이 유요함을 확인하고, 접근 토큰의 정보를 확인하여 제공할 데이터 항목 범위 및 유효기간이 정해진다.
Authorization Grant
Authorization Code
@startuml
ditaa
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI ---->| |
| User- | | Authorization |
| Agent -+----(B)-- User authenticates --->| Server |
| | | |
| -+----(C)-- Authorization Code ---<| |
+-|----|---+ +---------------+
| | ^ v
(A) (C) | |
| | | |
^ v | |
+---------+ | |
| |>---(D)-- Authorization Code ---------' |
| Client | & Redirection URI |
| | |
| |<---(E)----- Access Token -------------------'
+---------+ (w/ Optional Refresh Token)
@enduml
Implicit
@startuml
ditaa
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI --->| |
| User- | | Authorization |
| Agent -|----(B)-- User authenticates -->| Server |
| | | |
| |<---(C)--- Redirection URI ----<| |
| | with Access Token +---------------+
| | in Fragment
| | +---------------+
| |----(D)--- Redirection URI ---->| Web-Hosted |
| | without Fragment | Client |
| | | Resource |
| (F) |<---(E)------- Script ---------<| |
| | +---------------+
+-|--------+
| |
(A) (G) Access Token
| |
^ v
+---------+
| |
| Client |
| |
+---------+
@enduml
-
JavaScript 애플리케이션에서 많이 사용됨
-
access token이 노출되는 것을 전제로 함
-
PKCE(Proof Key for Code Exchange)
PKCE(Proof Key for Code Exchange) 지원은 모바일 디바이스에서 권한 코드 플로우를 수행할 때 보안을 추가하는 기능(RFC 7636에 정의됨)입니다.
— https://www.ibm.com/docs/ko/sva/9.0.7?topic=support-proof-key-code-exchange
-
-
refresh token을 지원하지 않음
-
이것을 가로채 사용자의 상호작용 없이 갱신이 가능하므로?
-
-
인증용 웹페이지에 접근하여 로그인/동의하고, 전달받은 리다이렉트 URL로 access token을 전달하는 것으로 이해함
-
그럼, 모바일에서는 redirect 처리를 어떻게 할 것인지?
-
redirect url을 전달받으면 변경될 가능성이 있으므로 별도 개발자센터를 통해서 전달받은 URL로 리다이렉트해줘야 할 것으로 보임
-
Resource Owner Password Credentials
@startuml
ditaa
+----------+
| Resource |
| Owner |
| |
+----------+
v
| Resource Owner
(A) Password Credentials
|
v
+---------+ +---------------+
| |>--(B)---- Resource Owner ------->| |
| | Password Credentials | Authorization |
| Client | | Server |
| |<--(C)---- Access Token ---------<| |
| | (w/ Optional Refresh Token) | |
+---------+ +---------------+
@enduml
Client Credentials
@startuml
ditaa
+---------+ +---------------+
| | | |
| |>--(A)- Client Authentication --->| Authorization |
| Client | | Server |
| |<--(B)---- Access Token ---------<| |
| | | |
+---------+ +---------------+
@enduml
Etc
- User
-
서비스 제공자와 소비자를 사용하는 계정을 가지고 있는 개인
- Consumer
-
Open API를 이용하여 개발된 OAuth를 사용하여 서비스 제공자에게 접근하는 웹사이트 또는 애플리케이션
- Service Provider
-
OAuth를 통해 접근을 지원하는 웹 애플리케이션(Open API를 제공하는 서비스)
- Consumer Secret
-
서비스 제공자에서 소비자가 자신임을 인증하기 위한 키
- Request Token
-
소비자가 사용자에게 접근권한을 인증받기 위해 필요한 정보가 담겨있으며 후에 접근 토큰으로 변환된다.
- Access Token
-
인증 후에 사용자가 서비스 제공자가 아닌 소비자를 통해서 보호된 자원에 접근하기 위한 키를 포함한 값.
- JWT
-
11