[OAuth] OAuth에 대한 간단한 정리
2021년 08월 08일, 21:40
인증 vs 권한부여
- 인증(Authentication)
- 시스템이 사용자를 안전하게 식별할 수 있는 과정
- 권한부여(Authorization)
- 시스템의 리소스에 사용자가 어느정도 엑세스할 수 있는지 결정하는 과정
OAuth를 사용하는 이유?
- 현재 소셜 인증 등으로 가장 널리 사용되는 방법
- 상대적으로 간편하고 안전하다.
다양한 인증 방법
- 쿠키와 세션을 이용한 인증
- 쿠키로 세션 ID를 저장하고 서버에서는 sessionid에 해당되는 곳에 클라이언트의 정보를 저장해서 인증
- 토큰을 이용한 인증
- 토큰의 정보를 검증하고, 해당 토큰에 있는 정보를 이용해서 인증
- JWT를 사용한 인증
- 토큰 인증과 비슷한데, header, payload, signature으로 이루어져있다.
- header에는 토큰타입, 해쉬 알고리즘
- payload에는 유저 정보(민감하지않은), 생성(client)자 정보, 생성 일시 등
- signature은 헤더에 정의된 알고리즘으로 비밀키를 이용해 헤더와 페이로드를 암호화한다.
- 모든 header, payload, signature은 Base64 URL-Safe로 인코딩
- Access Token과 Refresh Token을 함께 사용한 인증
- Access token만을 가지고 인증을 진행하면 단점들이 존재한다. token은 발행되고 나면 서버에서 관리할 방법이 없다. 따라서, access token의 만료 기간을 짧게 잡고, refresh token을 만들어 access token이 만료된 경우 refresh token을 이용해서 access token을 갱신하는 방식을 사용한다. refresh token은 access token보다 만료 시간을 길게 잡고 사용
Oauth2
- 기업들이 만든 인증 표준
- 2006년 v1이 나온 이후 여러가지 개선을 거쳐 현재 2.0이 사용됨
- https://oauth.net/2/
Oauth2의 목적
- 다양한 클라이언트 기기들의 인증을 간단히 하기 위해
- 제 3의 서비스에서 리소스 소유자의 인증을 거쳐 리소스 서버에 리소스를 요청할 수 있음
OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 supersedes the work done on the original OAuth protocol created in 2006. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices. This specification and its extensions are being developed within the IETF OAuth Working Group.
용어 정의
- Resource Owner: 일반적인 사용자
- Client: 서비스 제공자
- Authorization Server: 인증을 담당하는 서버 (ex: 깃헙 인증 서버)
- Resource Server: 리소스를 가지고 있고 클라이언트에게 제공해 주는 서버 (ex: 깃헙 데이터 서버)
인증 방법
- 4가지 인증 방법
- authorization code
- implicit
- resource owner password-credentials
- client credentials
Protocol flow
+--------+ +---------------+
| |--(A)- Authorization Request ->| Resource |
| | | Owner |
| |<-(B)-- Authorization Grant ---| |
| | +---------------+
| |
| | +---------------+
| |--(C)-- Authorization Grant -->| Authorization |
| Client | | Server |
| |<-(D)----- Access Token -------| |
| | +---------------+
| |
| | +---------------+
| |--(E)----- Access Token ------>| Resource |
| | | Server |
| |<-(F)--- Protected Resource ---| |
+--------+ +---------------+
Authorization Code
- 브라우저 등을 통해 리소스 오너가 직접 코드를 획득한 후 클라이언트에게 전달함
Implicit
- 브라우저 기반(JS)에서 직접 코드를 획득하는 방법
- 리소스 오너는 브라우저 등을 통해 액세스 토큰을 바로 획득함
- 클라이언트는 리소스 오너로부터 받은 액세스 토큰을 리소스 서버로 전달함
Resource Owner Password Credentials
- 사용자 아이디, 패스워드를 이용해서 직접 액세스 토큰을 얻어냄
- 클라이언트의 신뢰도가 매우 높을 경우 사용 (내 PC)
- 다른 방법이 불가능할 경우 사용
Client Credentials
- 서버 등에 의해 지정된 제한된 제한적 리소스 접근에만 사용 가능
- 보통 리소스 오너 = 클라이언트인 경우 사용 가능
Authorization Code Grant
+----------+
| 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)
Implicit Grant
+----------+
| 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 |
| |
+---------+
Note: The lines illustrating steps (A) and (B) are broken into two
parts as they pass through the user-agent.
액세스 토큰과 리프레시 토큰 활용
+--------+ +---------------+
| |--(A)------- Authorization Grant --------->| |
| | | |
| |<-(B)----------- Access Token -------------| |
| | & Refresh Token | |
| | | |
| | +----------+ | |
| |--(C)---- Access Token ---->| | | |
| | | | | |
| |<-(D)- Protected Resource --| Resource | | Authorization |
| Client | | Server | | Server |
| |--(E)---- Access Token ---->| | | |
| | | | | |
| |<-(F)- Invalid Token Error -| | | |
| | +----------+ | |
| | | |
| |--(G)----------- Refresh Token ----------->| |
| | | |
| |<-(H)----------- Access Token -------------| |
+--------+ & Optional Refresh Token +---------------+
참고자료
- https://aaronparecki.com/oauth-2-simplified/
- https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2
- 생활코딩 oauth 2.0
- https://tools.ietf.org/html/rfc6749(공식문서)