OAuth 2.0
이는 인증을 위한 개방형 표준 프로토콜로, Third-party 프로그램에게 리소스 소유자를 대신해서 리소스 서버에서 제공하는 자원에 접근 권한을 위임하는 방식을 제공한다.
Resource Owner는 Client를 인증하는 역할을 수행하고, 인증이 완료된 경우 동의를 통해 권한 획득 자격을 Client에게 부여한다. 권한을 얻은 Client는 해당 서비스에 접근이 가능하다. 이때 권한을 얻었다고 해당 서비스의 모든 리소스에 접근 가능한 것은 아니라 접근이 허용된 만큼만 리소스를 얻을 수 있다.
용어 정리
| 이름 | 설명 |
| Resource Owner | 리소스의 소유자로서 본인의 정보에 접근할 수 있는 자격을 승인하는 주체이다. 예를 들면 다른 써드 파티 어플리케이션에서 구글을 통해 로그인을 한다고 할 때, 구글 계정의 주인인 사용자를 의미한다. Resource Owner는 클라이언트를 인증(Authorize)하는 역할을 수행하고, 인증이 완료되면 동의를 통해서 권한 획득 자격(Authorization Grant)을 클라이언트에게 부여한다. |
| Client | Resource Owner의 리소스를 사용하고자 접근 요청을 하는 어플리케이션을 의미한다. |
| Resource Server | Resource Owner의 정보가 저장되어 있는 서버이다. 사용자 계정 정보가 저장되어 있는 구글 서버라고 생각하면 된다. |
| Authorization Server | 권한 서버이다. 인증 / 인가를 수행하는 서버로 클라이언트의 접근 자격을 확인하고 Access Token을 발급하여 권한을 부여하는 역할을 수행한다. |
- 인증: 인증, 접근 자격이 있는지 검증하는 단계이다.
- 인가: 리소스에 접근할 권한을 부여하고 리소스 접근 권한이 담긴 Access Token을 제공한다. 인증이 된 사용자에게인가가 이루어진다는 점에서 인증은 인가에 선행 되어야한다.
- Access Token: 리소스 서버에게서 리소스 소유자의 정보를 획득할 때 사용하는 토큰이다. 보안을 위해서 만료기간이존재하여 재발급을 위한 Refresh Token을 사용한다.
- Refresh Token: Access Token이 만료시 이를 재발급 받기 위한 용도로 사용하는 토큰이다.
OAuth 과정
1) 등록
클라이언트가 리소스를 사용하기 위해선 먼저 등록이 필요하다. 이 과정은 어떤 리소스 서버에 등록하느냐에 따라 다르지만 공통적으로 세가지를 가지게 된다.
- Client ID : 우리가 리소스 서버에 등록하고자한 클라이언트의 식별자이다.
- Client Secret : 클라이언트의 비밀번호이다. 외부에 노출되서는 안된다.
- Authorized redirect URIs : 리소스 서버가 Authorized code를 통해서 권한을 부여하는데 해당 코드는 Authorized redirect URIs로 반환된다.
2) Resource Owner의 승인
클라이언트가 등록이 되고 난 후에는 클라이언트에서 사용할 권한의 정도를 Resource Owner가 승인해주어야 한다.
예를 들어서 client 어플리케이션에서 구글에서의 기능을 사용하고자 한다고 하자.
이 경우 먼저 등록 과정을 거친 후, Resource Server인 구글에게 b와 c라는 기능을 사용하고자 요청한다.
구글 서버는 client가 등록되었는지 확인한 후 나에게 구글 로그인을 요청한다.
로그인이 완료되었다면 리소스 서버는 해당 Client ID값과 같은 Client ID 값이 존재하는지 확인한다. 그리고 해당
클라이언트 아이디의 Redirect URIs와 요청의 Redirect URIs가 동일한지 확인한 후 다르다면 작업을 중단한다.
만일 같다면 Resource Owner에게 해당 스코프 b,c에 해당하는 기능을 클라이언트에게 부여할지에 대한 요청을 보내게
된다.
허용이 되었다면, 해당 클라이언트는 b, c라는 스코프에 대한 기능이 1이라는 user id를 갖는 사용자에 대해서 허용되었다는 정보가 Resource Server에 저장된다.
3) Resource Server의 승인
Owner와 마찬가지로 Server도 승인을 해야한다.
먼저 Resource Server는 Authorization Code를 생성하여 이를 Resource Owner에게 전송한다.
또한 Resource Owner는 이를 클라이언트에게 전송한다.
authorization code를 부여받은 클라이언트는 코드와 redirect url, client id, client secret을 담아 리소스 서버의 url로 접속한다. 접속한 경우 리소스 서버는 해당 authorization code와 일치하는 코드가 존재하는지 확인한다.
존재한다면 발급한 authorization code가 어떤 클라이언트에게 발급한 것인지를 client id와 client secret를 통해서 확인한다.
4) 액세스 토큰 발급
authorization code는 어디까지나 access token을 발급하기 위한 장치이다.
따라서 resource server에서 클라이언트가 확인 되었다면 다시 재인증을 하지 않기 위해서 authorization code는 제거한다. 그 후 server는 access token을 발급한다.
발급한 access token은 클라이언트에게 전달되고, resource server는 앞으로 클라이언트가 해당 access token( = 4)로 접근할 때마다 user id( =1)에 해당하는 사용자의 기능 b, c의 사용을 허가해준다.
즉, 클라이언트는 resource owner의 b,c에 대한 기능을 인가받게 된 것이다.
Reference
OAuth 2.0 개념 총 정리 (tistory.com)
WEB2 - OAuth 2.0 : 2. 역할 (youtube.com)