oAuth2

Y·2022년 11월 14일

OAuth2란?

Open Authorization, Open Authentication

OAuth2.0이란 각종 웹, 모바일 어플리케이션에서 타사의 API를 사용하고 싶을 때 권한 획득을 위한 프로토콜(Protocol)이다. 구글, 페이스북, 카카오 등에서 제공하는 Authorization Server를 통해 회원 정보를 인증하고 Access Token을 발급받는다.

발급받은 Access Token을 이용해 타사의 API 서비스를 이용할 수 있다.

oAuth1과의 차이점?

기능의 단순화, 기능과 규모의 확장성 등을 지원하기 위한 목적
https를 통해 암호화를 하여 과정의 단수화
다양한 인증 방식이 제공
api 서버에서 인증서버와 리소스 서버가 분리

인증과 인가

Authentication(인증) : 접근 자격이 있는지 검증하는 단계
Authorization(인가) : 자원에 접근할 권한을 부여하는 것이다. 인가가 완료되면 리소스 접근 권한이 담긴 Access Token이 클라이언트에게 부여된다.

일반 로그인은 회원가입할 때 사용했던 아이디와 비밀번호를 통한 인증(Authentication)이라면 OAuth2.0은 타사 서비스(Google, facebook)의 이메일 정보에 우리가 만든 서비스의 접근을 허락(Authorization)하여 사용자를 인증(Authentication)한다.

Obtaining Authorization

OAuth2 프로토콜에서는 다양한 클라이언트 환경에 적합하도록 권한 부여 방식에 따른 프로토콜을 4가지 종류로 구분하여 제공한다.

Authorization Code Grant : 권한 부여 승인 코드 방식으로, 가장 많이 쓰이고 기본이 되는 방식간편 로그인 구현 시 사용되는 방식으로 클라이언트가 사용자를 대신하여 특정 자원에 접근을 요청할 때 사용되는 방식이다. 권한 부여 승인 요청 시 response_type을 code로 지정하여 요청한다.
Implicit Grant : 암묵적 승인 방식
Resource Owner Password Credentials Grant : 자원 소유자 자격증명 승인 방식
Client Credentials Grant: 클라이언트 자격증명 승인 방식

OAuth2 용어 정리

Resource owner (자원 소유자)

Resource server(구글, 페이스북, 카카오 등)의 계정을 소유하고 있는 사용자를 의미한다. (유저)

Client

구글, 페이스북, 카카오 등의 API 서비스를 이용하는 제 3의 서비스

즉 Resource Server에 접근하여 정보를 가져가는 클라이언트

Resource Server

OAuth2 서비스를 제공하고, 자원을 관리하는 서버

(ex. Google, Facebook..)

제어하고자 하는 자원을 갖고 있는 서버

Authorization Server(권한 서버)

권한을 관리해 주는 서버, Access Token, Refresh Token을 발급, 재발급 해주는 역할을 한다. 인증과 관련된 처리를 전담하는 서버

Access Token

Authorization Server로 부터 발급 받은 인증 토큰, Resource Server에 전달하여 서비스를 제공 받을 수 있다

Refresh Token

Authorization Server에 Access Token을 요청할 수 있는 토큰

주요 API parameters

동작 과정

1. 애플리케이션 등록

어떤 특정 Resource Server를 이용하기 위해서는, 해당 서비스에 내가 인증을 사용할 애플리케이션을 등록해야 한다. (해당 에시는 네이버 로그인)

(Resource Server의 특정 API를 사용할 것이라고 등록)

Client ID : 내 애플리케이션을 식별하는 아이디
Client Secret : 그것에 대한 비밀번호 (외부에 절대 노출되면 안됨)
Authorized redirect URIs : Resource Server가 권한을 부여하는 과정에서 authorized code를 우리에게 전달해주는데, 그때 이 주소로 전달해달라고 알려주는 것

⇒ 이와 같이 Resource Server는 이 Client를 식별할 수 있는 Client ID와 Client Secret을 발급한다.

⇒ Resource Server는 해당 Client ID로 어떤 웹 사이트에서 OAuth 인증을 요청하는지를 자체적으로 식별할 수 있다.

2. Resource Owner의 승인

등록 후 Resource Server와 Client 양쪽은 위의 3가지 정보를 알게된다.

이제, Resource Owner(사용자)가 우리 애플리케이션에 접속할 것이고, 화면의 로그인 버튼 클릭 등을 통해 인증에 대한 동의하게 된다.

동의 정보를 포함하여 callback url로 전송된다.

(ex. 네이버 로그인 https://nid.naver.com/oauth2.0/authorize?response_type=code&client_id=CLIENT_ID&state=STATE_STRING&redirect_uri=CALLBACK_URL )

유저가 로그인하여 로그인을 성공했으면, Resource Server는 위의 링크에서의 client_id값이 자신이 갖고 있는 client id 값과 동일한지 확인
접속을 시도하고자 하는 요청의 redirect uri 값과 자신이 갖고 있는 redirect uri 값과 동일한지 확인
동일하다면, 유저에게 해당 scope에 해당하는 권한을 Client에게 부여할 것인지 확인하는 메시지를 보여준다.

허용한다면, 허용했다는 정보가 Resource Server로 전송될 것이고, user_id와 (어떤 권한을 허용했는지) scope에 대한 정보를 저장한다.

3. Resource Server의 승인

바로 access token을 발급하기 전에, authorization code (임시 비밀번호)를 먼저 발급한다
Resource Server는 이 authorization code를 Resource Owner에게 전송한다

(ex. Location: https://client/callback?code=3

=> Resource Server가 response의 헤더에 Location 값을 주면, Resource Owner의 웹 브라우저는 해당 주소로 이동 )

( code=3은 Resource Server가 준 authorization code )

⇒ 이제 Client는 해당 authorization code와 함께, client_secret 정보를 Resource Server에게 전송하여 이 모든 것이 동일한지 확인하여 결론적으로 access token을 발급하게 된다

4. Access Token 발급

Resource Server는 authorization code값으로 이미 인증을 했기 때문에, 이를 삭제하고, accessToken을 발급함

Client에게 accessToken을 전달

5. Refresh Token

accessToken은 수명이 있다.

즉, 시간이 흐른 후 Access Token이 만료되면, 리소스 서버는 이후 요청들에 대해 오류를 응답하게 된다. Client는 받아둔 Refresh Token을 권한 서버에 보내어 새로운 Access Token을 요청한다. 갱신 요청을 받은 권한 서버는 Refresh Token의 유효성을 검증한 후, 문제가 없다면 새로운 액세스 토큰을 발급해준다다. 이 과정에서 옵션에 따라 Refresh Token도 새롭게 발급 될 수 있다.