OAuth 2.0

현장 실습을 하면서 OAuth 2.0에 대해 조사하고 발표를 했었는데, 다시 한 번 제대로 정리를 해야할 것 같아서 정리를 해보았습니다. <초보자>가 정리한 것이라 틀린 점이 있을 수도 있습니다. 아래는 OAuth2.0 네 가지 방식들 중 Authorization code grant type을 중점적으로 설명한 내용입니다.

먼저, OAuth란?

user가 ‘나의 서비스’에 가입하려고 할 때 구글이나 페이스북과 같은 ‘다른 서비스’의 아이디와 비밀번호를 이용하여 가입이 가능하도록 구현을 한다면, 보안상에도 문제가 있을 것이고 신뢰성도 떨어질 것입니다. 이를 구현하기 위해서는 OAuth를 이용하면 가능합니다. 다시 말해 구글로 로그인, 페이스북으로 로그인 같은 기능들이 OAuth를 통해 구현한 기능이라고 보면 됩니다.

먼저 OAuth에는 네 가지 object가 있습니다. Resource Owner, Client, Resource Server, Authorization Server이렇게 네 가지 입니다. 간단히 설명하자면 resource owner은 유저입니다. client는 내가 만든 서비스라고 할 수 있습니다. resource server는 다른 서비스 즉, 구글이나 페이스북이 될 수 있습니다. authorization server는 내 서비스에서 구글이나 페이스북으로 접근할 수 있게 해 주는 서버라고 할 수 있겠습니다.

OAuth 2.0에는 네 가지 인증 방식이 있는데 서치하고 공부하면서 계속 헷갈렸던 부분이, 인증 방법을 4가지로 구현을 할 수 있다는 의미가 아니라 상황에 따라 4가지로 나뉜다는 의미였습니당,,,(나만 헷갈렸남...?ㅎㅎ) 여튼 그 4가지 방식은 다음과 같습니다.

1. Resource Owner credential grant type(password grant type)

2. Authorization Code grant type

3. Implicit grant type

4. Client Credential grant type

간단하게 설명해서 페북으로 예를 들자면, Password grant type은 자사 앱에 로그인할 때 사용하는 방식이며, Authorization Code grant type과 Implicit grant type은 페북 아이디로 로그인하며, 페북 프로필 가져오기 등의 기능을 할 때 사용합니다. Client Credential grant type은 user가 없이 직접 resource server로 접근할 때 사용하는 방식입니다. 아래에 설명할 부분은 2번 Authorization Code grant type입니다.

[OAuth 2.0]

클라이언트가 서버에 등록하기 위한 필수 요소 세 가지는 client ID, client secret, authorized redirect URIs입니다. 다시 말해, 클라이언트를 google developer와 같은 곳에 등록을 하게 되면 client ID와 client secret을 얻게 됩니다. client ID는 우리가 만든 어플리케이션의 식별자 ID이며, secret은 그에 대한 비밀번호이고, redirectg URIs는 리소스 서버가 권한을 부여하는 과정에서 authorized code라는 것을 전달하는데, 이 코드를 이 URI로 전달합니다.

여기서 user를 Resource Owner라고 하며, 내 서비스를 Client, 다른 서비스를 Resource Server라고 합니다. Client와 Resource Server 사이에 Authorization Server가 있는데, 이는 Client가 Owner에게 허가를 받고 code와 access token을 부여해 주는 서버입니다. 다음 설명에서는 편의상 Resource Server와 Authorization Server를 하나로 통일(Authorization Server)하여 설명하려고 합니다.

1. 먼저 owner가 client에 접근하게 되면, client는 server의 기능이 필요하기 때문에 server에 먼저 로그인해야 된다는 화면을 띄워줍니다. 이때 ‘구글로 로그인’ 버튼의 주소는 [http://서버 주소&scope=b,c&client_ID=1&redirect_uri=리다이렉트 주소]의 형식으로 되어있습니다.

2. owner가 이 버튼을 누르면 server로 접속하게 됩니다. server에 로그인을 성공하게 되면 주소의 client id 값이 server에 등록된 client id값과 동일한지 확인하고, redirect URI도 확인한 후 모두 같으면 client에서 요청한 scope를 제공하는데 동의할 것인지의 여부를 owner에게 묻습니다.

3. owner가 허용하게 되면 허용했다는 메시지를 server에게 전송하고, server가 전송을 받으면 client에서 요청한 기능(scope)를 server에 저장합니다.

4. scope를 server에 저장하고, 정보가 저장된 authorized code를 발급합니다. 이 authorized code를 owner에게 전송하는데, 헤더값으로 [location:https://redirect_uri?authorized_code=3]을 줍니다. 이를 통해 owner를 redirect 시킬 수 있습니다. 이를 통해 client가 authorized code=3이라는 것을 알 수 있게 됩니다.

5. client가 authorization code를 획득하면 resource server로 정보를 전송하는데 형식은 다음과 같습니다.

• [https://서버주소/?grant_type=authorization_code&code=3&redirect_uri=https://리다이렉트주소&client_id=1&client_secret=2]

6. authorization code와 client secret 두 개를 결합해서 resource server에 전송합니다. client로 부터 받은 authorization code를 확인한 후 server에서 가지고 있는 코드 정보를 확인하고, 모든 정보가 일치하면 authorization code를 삭제하고 access token을 client에 발급해줍니다.

• client ID는 user ID가 아니라 어플리케이션의 식별자 ID이다.

• 등록 과정은 developer에서 client를 등록하는 과정을 말한다(ID와 secret을 server에 저장함).

• 리다이렉트 주소는 client(어플리케이션) 주소이다. call back.

• header에 location을 추가하면 설정한 주소로 페이지 이동이 가능하다.

[전체적인 Authorization code grant 흐름]

<조사하면서 계속 헷갈렸던 부분>

• Auth와 OAuth의 차이는? 토큰을 사용하느냐 사용하지 않느냐의 차이이다. 보안을 강화하기 위해 나온 방식이 OAuth이다. Auth는 Authentication(인증), OAuth는 Authorization이다(권한).

• OAuth 서버라는 것이 무엇을 의미하는 것인가? 말 그대로 oauth2.0을 구현하는 것을 말하는 것 같다.