OAuth

개념

이미지 출처: naver developer

위같은 로그인 서비스들은 별도로 application에 회원가입하지 않아도 로그인을 할 수 있게 한다. 해당하는 플랫폼에 계정만 있다면 application의 서비스를 이용할 수 있다. 이렇게 외부 서비스에서도 인증을 가능하게 하고 그 서비스의 API들을 이용하게 해주는 것이 **OAuth**(Open Authorization)이다.

현재 OAuth 2.0의 정확한 개념은 다양한 플랫폼 환경에서 권한 부여를 위한 산업 표준 프로토콜이다.

배경

기존 비밀번호 인증 방식에서는 여러 문제가 있었는데, 다음과 같다.

• 사용자가 제 3의 application에게 id/pw를 제공하기 꺼려한다.
• 각종 application에 id/pw를 계속 제공하는 경우 보안에 취약해진다.
• Id/pw를 알고 있는 application은 모든 권한을 가지므로 위험 부담이 생긴다.
• pw를 변경한다면 application은 동작할 수 없으며, 모든 application에 대해 갱신할 필요가 생긴다.

예를 들어, 내가 사용하려는 app A가 있고, 여기서 facebook에 글을 올린다고 가정해보자.

• A에 내 facebook 계정의 id/pw를 저장해야 한다.
• Facebook에 글을 저장하기 위해서는 글을 올리는 권한만 있으면 되는데, id/pw를 가지고 있으므로 그 외의 모든 권한을 갖게 된다.
• App A 자체의 보안이 취약하다면 A 계정 뿐만 아니라 facebook의 id/pw도 보안에 위험해질 수 있다.
• Facebook의 pw를 바꾼다면, A 계정에서도 갱신을 해주어야 하며, 갱신하지 않으면 원하는 동작이 수행되지 않는다.

최초 OAuth(1.0a)에서는 구현이 복잡했고, access token이 만료되지 않았으며 HMAC을 통해 암호화하였다. 반면 OAuth 2.0에서는 기능을 단순화하였고, 암호화를 https에 맡기며 다양한 인증 방식을 지원한다.

용어

OAuth에서 사용하는 주요 용어를 몇 가지 살펴 보자.

• Resource Owner: Client와 resource server를 사용하는 계정을 가지고 있는 개인
• Client: Open API를 이용하여 개발된 OAuth를 사용하여 resource server에게 접근하는 웹사이트 또는 application
• Resource Server: OAuth를 통해 접근을 지원하는 웹 application, Open API를 제공하는 서버
• Authorization Server: 사용자의 동의를 받아서 권한을 부여하는 서버

인증 방식 종류

인증 방식 종류에는 다음 네 가지가 있는데, 주로 authorization code grant가 많이 사용된다고 한다.

• Authorization Code Grant
• Implicit Grant
• Resource Owner Password Credentials Grant
• Client Credentials Grant

인증 프로세스

Register

Client가 resource server를 이용하기 위해서는, resource server에 승인을 받아야 하는데 이 과정을 register라고 한다. 네 가지 인증 방식에서 공통적으로 아래 세 가지를 이용한다.

• Client ID: Client를 식별하는 식별자 (노출 상관 없음)
• Client Secret: 식별자에 대한 비밀번호 (노출되면 안 됨)
• Authorized redirect URI: Resource server가 authroized code를 전달할 URI

Authorization Code Grant 인증 프로세스

이미지 출처: https://cheese10yun.github.io/oauth2/

먼저 Client가 파라미터로 Client ID, Redirect URL, Response_type을 code로 지정하여 Authorization Server에 전달한다. 여기서 Response_type을 token으로 줄 수도 있는데, 이렇게 하면 Implicit Grant 방식이 된다고 한다.

정상적으로 인증이 되면, 권한 부여 코드를 Client에게 보낸다.

성공적으로 권한 부여 코드를 받은 Client는 이 코드를 이용하여 Access Token을 Authorization Server에 추가로 요청한다. 이 때 Client ID, Client Secret, Redirect URL, Grant type(인증 타입)을 보낸다.

마지막으로 Access token을 응답 받으면 Access token을 사용하여 Resource Server에 API를 호출할 수 있다.

Kakao Oauth 실습

이미지 출처: Kakao developers

Request URL을 보면, GET방식으로 요청하며 oauth로 시작하는 것을 알 수 있다.

위에서 register에는 client id와 client secret, redirect uri를 요구한다고 언급했는데,
실제로 request parameter에 필수 요소에 client id와 redirect uri가 들어가있는 것을 확인할 수 있다.

여기서 client secret이 없는 것은, client secret 개념이 client_id로 이용되며 client id 개념은 내 애플리케이션 정보에 들어가면 확인할 수는 있지만 굳이 사용하지 않는 것 같다.

그리고 Authorization Code Grant 방식에서는 response_type을 code로 고정하여 이용한다고 했는데, 카카오에서도 code로 고정하여 이용하는 것을 보면 authorization code grant 방식을 이용하는 것 같다.

이렇게 하면 인가 코드, 즉 아까 살펴본 개념에서의 용어로 권한 부여 코드를 받을 수 있다.

python으로 간단히 구현한 코드를 돌려보면 응답으로 access token과 refresh token, access token과 refresh token의 유효기간, scope이 나오는 것을 알 수 있다.

scope라고 하는 것은 application에서 권한을 제어할 때 이용하는 기능이다. 여기서는 message 기능을 이용했기 때문에 이렇게 scope가 나온다.