[23.10.10/TIL] OAuth 2.0 이론적 접근

OAuth 2.0

1. 개념

💡 the industry-standard protocol for authorization

 

인터넷 사용자들이 ID/PW를 제공하지 않고 다른 웹사이트상의 자신들의 정보에 대해 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준

인증은 유저가 진행, 이후 권한은 외부 어플리케이션이 사용 (을 위한 표준규약)

---

2. OAuth 의 Roles 사전 설명

a. Resource Owner

b. Client

클라이언트는 애플리케이션 또는 서비스를 개발하거나 운영하는 개발자 또는 조직에 의해 구현

c. Authorization Server

기업 내부 시스템에서 자체 인증 서버를 구현 or 외부적으로 구현하여 제공받을 수 있음

d. Resource Server

해당 리소스를 소유하거나 관리하는 개체 또는 조직에 의해 구현

---

3. OAuth 2.0의 발전

OAuth 1.0의 문제점

• Scope에 대한 개념이 존재하지 않음
• 역할이 확실히 나누어지지 않음
• 토큰의 유효기간 문제
• Client 구현 복잡성
• 제한적인 사용환경

OAuth 2.0의 개선점

• Scope 개념 형성
• Authz server 와 Resource server로 서버의 역할의 분리
• Refresh Token을 통해 토큰 탈취 문제 해소 및 사용자 경험 개선
• Bearer Token + TLS 를 활용하여 Client 구현 복잡성 해소
• “Grant”라는 개념을 제시

---

OAuth Scope

사용자 계정에 대한 애플리케이션의 액세스를 제한하는 OAuth 2.0의 메커니즘

OAuth does not define any particular values for scopes, since it is highly dependent on the service's internal architecture and needs.

Scope는 서비스의 내부 아키텍처와 필요에 의존한다!

실제 사용시 앱에서 사용하는 범위에 대한 유효성의 인증이 필요하다

Google API의 OAuth 2.0 범위  |  Authorization  |  Google for Developers

Google API의 OAuth 2.0 범위  |  Authorization  |  Google for Developers

Google Calendar API 범위 선택  |  Google for Developers

Google Calendar API 범위 선택  |  Google for Developers

ex) 구글의 캘린더

The authorization and token endpoints allow the client to specify the
   scope of the access request using the "scope" request parameter.

---

Server의 선택적 역할 분리

서버를 역할에 따라 분리함 (1.0의 모호한 역할에 대한 분리 진행)

 

< authorization server >

Resource Owner 인증

인가 토큰 발급

 

< resource server >

보호된 리소스 관리

---

기존에 없던 Refresh Token의 생성

Access Token의 만료기간을 짧게 두어 토큰 탈취의 위험성을 낮추고

Refresh Token: 유저와 상호작용 없이 새로운 Access Token을 발급받을 수 있도록 함

작동 방식

 

• B: authorization server에게 Authorization Grant를 제시하며 요청한 Access 토큰을 Refresh 토큰과 함께 받음
• E, F: Access 토큰을 활용하여 자원을 활용하다가 만료된 토큰이라던지 등의 문제를 client가 알면 G단계를 실행
• G, H: 같이 응답받은 Refresh 토큰을 다시 authorization server로 보내서 새로운 Access 토큰을 발급 (선택적으로 Refresh 토큰을 같이 받을 수 있음)

---

Bearer Token + TLS 를 활용하여 Client 구현 복잡성 해소

This specification defines the use of bearer tokens 
over HTTP/1.1 [RFC2616] using Transport Layer Security (TLS) [RFC5246] 
to access protected resources

Bearer Token?

"Bearer(소지자)"를 나타내며, 토큰을 소지한 클라이언트가 권한을 가진 것으로 간주하게 됨 (소지 자체가 권한!)

HTTP 헤더에 포함되어 리소스 요청과 함께 전송 (예시)

GET /api/resource HTTP/1.1
Host: example.com
Authorization: Bearer <access_token>

TLS? [RFC 5246]

Transport Layer Security (TLS)

The primary goal of the TLS protocol is to provide privacy and data integrity between two communicating applications.

 

---

OAuth 2.0 Grant

클라이언트 애플리케이션이 액세스 토큰을 얻기 위해 인증 서버 또는 권한 서버에게 제공하는 권한 부여 방법

→ 기존 웹을 중점으로 만들어졌기 때문에 현대의 다양한 디바이스에 적용하기 복잡한 문제가 있었음

“Grant”를 제시하며 4가지 방식을 소개함

---

4. OAuth 2.0 Grant

4.1 Authorization Code Grant에 중점을 두어 공부

RFC 6749: The OAuth 2.0 Authorization Framework

RFC 6749: The OAuth 2.0 Authorization Framework

 

4.1 Authorization Code Grant

웹에서의 동작으로 설명

User Agent 는 웹 브라우저 (크롬 등)라고 볼 수 있다

A)

Client 는 resource owner의 user agent를 authorization endpoint로 directing 하면서 flow 시작

클라이언트는 client identifier, requested scope, local state, a redirection URI (접근이 허용되거나 거절되면 authorization server가 user-agent에 다시 보낼 URI) 를 포함

B)

The authorization server authenticates the resource owner (viathe user-agent)

& resource owner가 클라이언트의 요청을 승인하나 거부하나 판단

C)

리소스 소유자가 액세스를 승인하면 authorization server는 리다이렉션 URI를 사용하여 사용자 에이전트를 클라이언트로 리디렉션

리디렉션 URI에는 권한 코드와 클라이언트가 이전에 제공한 로컬 상태가 포함

---

→ D 와 E 는 토큰의 재발급의 과정임

D)

클라이언트는 이전 단계에서 받은 권한 코드를 포함하여 권한 서버의 토큰 엔드포인트에서 액세스 토큰을 요청

요청을 할 때 클라이언트는 권한 서버와 인증을 수행

클라이언트는 authorization code for verification를 받기 위해 redircetion URI 를 포함

E)

authorization server는 클라이언트를 인증하고

authorization code의 유효성을 검사하며,

redircetion URI가 이전 단계에서 클라이언트를 리디렉션할 때 사용한 URI와 일치하는지 확인

유효한 경우, 권한 서버는 액세스 토큰과 (리프레시 토큰: optionally)을 응답

 

 

OAuth 2.0 — OAuth

OAuth 2.0 — OAuth