[Web] OAuth의 개념, OAuth의 동작 메커니즘

OAuth

구글, 페이스북, 트위터 등의 다양한 플랫폼의 특정 사용자 데이터에 접근하기 위해, 제 3자 클라이언트가 사용자의 접근 권한을 위임(Delegated Authorization) 받을 수 있는 표준 프로토콜

 

즉, 우리가 제공하는 서비스를 이용하는 유저에 대하여, 타사 플랫폼 정보에 접근하기 위해 권한을 위임받는 것

 

OAuth 2.0의 구성요소

1. Resource Owner

웹 서비스를 이용하려는 사용자. 즉, 자원(개인정보)을 소유하는 자

 

2. Client

자사 또는 개인이 만든 애플리케이션 서버
(Resource server에게 필요한 자원을 요청하고 응답하는 관계라는 관점에서, 클라이언트라고 칭함)

 

3. Authorization Server

권한을 부여하는 서버 (=인증에 사용할 아이템을 제공하는 서버)

- 사용자로부터 ID, PW를 전달받아, Authorization Code를 발급한다.

- Client로부터 Authorization Code를 전달받아, Token을 발급한다.

 

4. Resource Server

사용자의 개인정보를 갖고 있는 애플리케이션 회사 서버 (구글, 페이스북, 카카오 등)

- Client로부터 Token을 전달받아, 개인정보를 응답한다.

 

5. Access Token

자원에 대한 접근 권한을 Resource Owner가 인가하였음을 나타내는 자격증명

 

6. Refresh Token

Access Token에 비해 비교적으로 긴 만료기간을 가진 토큰

(access token이 만료되었지만 refresh token이 유효하다면, refresh token을 통해 access token을 재발급 받아, 재 로그인할 필요가 없도록 한다.)

 

OAuth 동작 메커니즘

0. 어플리케이션 등록

Client를 Resource Server에 등록하는 작업이다.

이 과정에서, Redirect URI (=인증을 성공한 사용자를 리디렉션 시킬 위치)를 등록해야 한다.

어플리케이션 등록이 완료되면, Client는 Client ID와 Client Secret을 얻는다.(access token 획득할 때 사용)

 

1, 2. 로그인 요청

OAuth 프로세스를 시작하기 위해, Client는 사용자의 브라우저를 Authorization Server로 보낸다.

Authorization URL에 클라이언트의 정보를 담은 매개변수를 쿼리스트링을 포함하여 보낸다.

https://authorization-server.com/auth?response_type=code
&client_id=29352735982374239857
&redirect_uri=https://example-app.com/callback
&scope=create+delete

• response_type: 'code'로 설정해야, 인증 성공 후 Authorization Code를 받을 수 있다.
• client_id: 애플리케이션을 생성했을 때 발급받은 Client ID
• redirect_uri: 애플리케이션을 생성했을 때 등록한 Redirect URI
• scope: 클라이언트가 부여받은 리소스 접근 권한

 

3, 4. 로그인 페이지 제공, ID/PW 제공

사용자는 로그인 페이지에서 ID, PW를 입력하여 인증을 진행한다.

 

5, 6. Authorization Code 발급, Redirect URI로 리다이렉트

사용자가 입력한 ID, PW에 따라 인증이 성공했다면, Authorization Server는 Authorization Code를 발급한다.

발급된 Authorization Code를 포하마여, 사용자를 Redirect URI으로 리디렉션 시킨다.

※ Authorization Code는 Access Token 획득을 위한 임시코드로, 수명이 매우 짧음

 

7, 8. Authorization Code와 Access Token 교환

Client는 Authorization Code를 Authorization Server에 전달하여, Access Token을 응답받는다.

Client는 사용자의 Access Token을 저장한다.

 

여기서, Access Token은 Resoure Server에서 사용자 정보에 접근이 가능하도록 하기 때문에, 제 3자가 가로채지 못하도록 HTTPS 연결을 통해서만 사용될 수 있다.

 

9. 로그인 성공

위 과정을 성공적으로 마치면, Client는 사용자에게 로그인이 성공하였음을 알린다.

 

10~13. Access Token으로 리소스 접근

로그인을 성공한 사용자가 Resource Server의 리소스(즉, 사용자의 정보)가 필요한 기능을 Client에게 요청하면, Client는 저장해놓은 Access Token을 사용하여 제한된 리소스에 접근하고, 사용자에게 자사의 서비스를 제공한다.

 

 

Authorization Code를 발급하는 이유?

Redirect URI를 통해 Authorization Code를 발급하는 과정이 생략된다면, Authorization Server는 Redirect URI를 통해 Access Token을 전달해야 한다. Redirect URI를 통해 데이터를 전달하기 위해서는 URL 자체에 데이터를 실어 전달하는 방법 밖에 존재하지 않기 때문에, 브라우저를 통해 데이터가 곧바로 노출되는 문제가 발생한다.

 

즉, Access Token의 노출로 인한 보안 사고를 방지하기 위해, Authorization Code를 사용한다.

 

 

 

참고

https://hudi.blog/oauth-2.0/

https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-OAuth-20-%EA%B0%9C%EB%85%90-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC