ㅁ OAuth 2.0
OAuth 2.0은 권한 부여를 위해 광범위하게 사용되는 공개 표준으로, 사용자에게 권한을 위임받은 서드파티 클라이언트 애프리케이션이 사용자를 대신해 보안 리소스에 접근할 수 있게 한다.
- 자원 소유자(Resource Owner): 최종 사용자.
- 클라이언트(Client): 최종 사용자의 권한을 위임받아 보안 API를 호출하려는 서드 파티 애플리케이션(예: Web App, Native Mobile App)
- 자원 서버(Resource Server): 보호 대상 자원에 대한 API를 제공하는 서버
- 권한 부여 서버(Authorization server): 자원 소유자(최종 사용자)를 인증하고 자원 소유자의 승인을 받아서 클라이언트에게 토큰을 발급한다. 사용자 정보 및 사용자 인증은 보통 ID 제공자(IdP, Identity Provider)에게 위임된다.
권한 부여 서버에 등록된 클라이언트는 클라이언트 ID(Client ID)와 클라이언트 시크릿(Client Secret)을 발급받는다.
클라이언트는 암호와 마찬가지로 클라이언트 시크릿을 보호해야 한다. 클라이언트는 Redirect-URI를 등록해야 하며, 권한 부여 서버는 사용자 인증을 거쳐 발급한 인증 코드(Grant Code)와 토큰(token)을 리다이렉트 URI로 전달한다.
사용자는 자신의 자격 증명을 클라이언트 애플리케이션에 공개하는 대신, 클라이언트 애플리케이션이 사용자를 대신해 특정 API에 접근하는 것을 허락한다.
접근 토큰엔 시간 제한이 있으며 OAuth 2.0 스코프를 사용해 접근 권한을 제한한다.
권한 부여 서버는 클라이언트 애플리케이션에 재발급 토큰(refresh toekn)을 발급할 수 있으며, 클라이언트 애플리케이션은 이를 사용해 사용자의 관여 없이 접근 토큰을 새로 발급 받을 수 있다.
OAuth 2.0 Spec에서는 Access Token 발급을 위한 권한 승인 흐름을 네가지로 정의하고 있다.
- 권한 코드 승인 흐름(Authroization code grant flow):
가장 안전하지만 가장 복잡한 승인 흐름이다. 이 권한 승인 방식을 사용하면 사용자는 웹 브라우저로 권한 부여 서버와 상호 작용해 클라이언트 애플리케이션에게 권한을 위임한다. 다음 다이어 그램을 참고한다.
1. 클라이언트 애플리케이션은 웹 브라우저를 통해 사용자를 권한 부여 서버로 보내고 권한 승인 흐름을 시작한다.'
2. 권한 부여 서버는 사용자를 인증하고 사용자의 동의를 요청한다.
3. 권한 부여 서버는 사용자를 인증 코드 (grant code)와 함께 클라이언트 애플리케이션으로 리다이렉트한다.
권한 부여 서버는 클라이언트가 1단계에서 지정한 리다이렉트 URI로 인증 코드를 전송한다.
인증 코드는 웹 브라우저를 통해 클라이언트 애플리케이션으로 전달되는데,
악의적인 자바스크립트(Java Script)코드가 Authentication (인증 코드)를 가로챌 수 있는 안전하지 않은 환경이므로 짧은 시간에 걸쳐 단 한번만 허용된다.
4. 클라이언트 애플리케이션은 Authentication Code (인증 코드)와 Access Token (접근 토큰)을 교환하고자 서버 측 코드를 사용해 권한 부여 서버를 다시 호출한다.
클라이언트 애플리케이션은 권한 부여 서버로 Auth code (인증 코드)를 보낼 때 클라이언트 ID와 클라이언트 시크릿도 함께 보내야 한다.
5. 권한 부여 서버는 Access Token(접근 토큰)를 발급해 클라이언트 애플리케이션으로 보내며, 선택적으로 Refresh Token(재발급 토큰)을 발급 및 반환 할 수도 있다.
6. 클라이언트는 접근 토큰을 사용해 자원 서버가 공개하는 보안 API에 요청을 보낸다.
이 내용을 시퀀스 다이어그램으로 표현하면 아래와 같다.
ㅇ. 기본적인 OAuth 수행 절차
ㅇ. Auth Code Grant 과정
ㅇ 리프레시 토큰을 주는 과정을 추가로 표현하면
- 묵시적 승인 흐름 (Implicit grant flow)
이 흐름 또한 웹브라우저 기반이지만 단일 페이지 웹 애플리케이션과 같이 클라이언트 시크릿을 안전하게 보호할 수 없는 클라이언트 애플리케이션을 대상으로 한다. 권한 부여 서버에서 인증 코드 대신 접근 토큰을 받으며, 권한 코드 승인 흐름에 비해 안정성이 낮으므로 재발급 토큰은 요청할 수 없다.
- 자원 소유자 암호 자격 증명 승인 흐름(Resource Owner Password Credentials grant flow)
클라이언트 애플리케이션이 웹 브라우저와 상호 작용할 수 없는 경우에 이 승인 흐름을 사용한다. 이 승인 흐름을 사용하면 사용자는 자신의 자격 증명을 클라이언트 애플리케이션과 공유해야 하며, 클라이언트 애플리케이션은 이 자격 증명을 사용해 접근 토큰을 얻는다.
- 클라이언트 자격 증명 승인 흐름(Client Credentials grant flow)
클라이언트 애플리케이션이 특정 사용자와 관련 없는 API를 호출해야 하는 경우에 이 승인 흐름을 사용한다. 클라이언트는 자체 클라이언트 ID와 클라이언트 시크릿을 사용해 접근 토큰을 얻는다.
https://tools.ietf.org/html/rfc6749
RFC 6749 - The OAuth 2.0 Authorization Framework
[Docs] [txt|pdf] [draft-ietf-oaut...] [Tracker] [Diff1] [Diff2] [IPR] [Errata] Updated by: 8252 PROPOSED STANDARD Errata Exist Internet Engineering Task Force (IETF) D. Hardt, Ed. Request for Comments: 6749 Microsoft Obsoletes: 5849 October 2012 Category:
tools.ietf.org
https://www.oauth.com/oauth2-servers/map-oauth-2-0-specs/
Map of OAuth 2.0 Specs - OAuth 2.0 Simplified
The OAuth 2.0 Core Framework (RFC 6749) defines roles and a base level of functionality, but leaves a lot of implementation details unspecified. Since the
www.oauth.com
ㅁ OpenID Connect 소개
OIDC(OpenID Connect)는 클라이언트 애플리케이션이 사용자의 신원을 확인하게 하려고 OAuth2.0에 추가된 기능이다. OIDC를 사용하면 승인 흐름이 완료된 후 클라이언트 애플리케이션이 권한 부여 서버에서 받아오는 토큰인 ID 토큰이 추가된다.
ID Token은 JWT(Json Web Token)으로 인코딩되며, 사용자 ID, 이메일 주소와 같은 다수의 클레임을 포함한다. ID Token은 JSON 웹 서명으로 디지털 서명된다. 클라이언트 애플리케이션은 권한 부여 서버의 공개 키로 디지털 서명을 검사함으로써 ID Token의 정보를 신뢰할 수 있다.
ID Token과 같은 방식으로 접근 토큰을 인코딩하고 서명할 수 있지만, 사양에 따른 필수 사항은 아니다. 끝으로 OIDC는 Discovery Endpoint를 정의하고 있는데 이는 주요 엔드포인트에 대한 정보를 제공하기 위한 표준이다.
주요 엔드포인트로는 JWKS엔드포인트(jwks_uri)와 권한 부여 엔드포인트(authorization_endpoint), 사용자 정보 엔드포인트(user-info endpoint)가 있다.