OAuth 2.0 ?
내가 만든 사이트에서 로그인할 때 Google, Facebook, Naver와 같은 사이트에 등록된 사용자 정보를 통해 로그인을 할 수 있다.
만약 내가 만든 Server가 Google, Naver와 같은 사이트에서 등록된 사용자 정보를 활용할 수 있는 권한을 획득할 수 있다면 위와 같은 기능(로그인 등)을 구현할 수 있는데 이러한 기술을 OAuth라고 한다.
여기서 권한은 해당 사이트에서 Access Token을 발급받아 사용할 수 있다.
OAuth 구현 시 바라 본 관계를 정리해본다면
- Resource Owner :
사용자(User) - Client :
내 서버 - Resource Server(+Authorization Server) :
Google, Facebook, Naver와 같이 내 정보를 가지고 있는 API
OAuth 등록 (Register)
🔎 Resource 서버 등록
기능이 필요한 Facebook, Naver의 developers 사이트에 들어가서 Client Id, Authroized redirect URLs 등록하게 되면, Client Secret을 부여해 준다.
여기서 Client Secret은 최종적으로 Access Token을 발급받기 위해 필요한 것이다.
(Client Id는 외부에 노출 될 수도 있지만 Client Secret이 노출되면 보안상 매우 위험)
📌 Client Id
우리가 만들고 있는 어플리케이션의 식별자
📌 Client Secret
비밀 Key
📌 Authorized redirect URls
Authorized Code(임시 비밀번호)를 전달해줄 주소인증
💡 등록 과정 후 Client, Resource Server는 Client Id, Client Secret, redirect URL를 알고 있으며
Client는 redirect url에 해당하는 페이지를 구성하고 준비해 놔야 한다.🔎 인증 과정
1. Resource Owner -> Client
- Resource Server 정보가 필요한 기능 요청 (로그인 등)
2. Client -> Resource Owner
-
Resource Server 인증이 필요하다는 메세지 혹은 로그인(인증) 할 수 있도록 하는 url 링크 제공
-
해당 링크의 경우 Client_id, 필요한 기능(scope), redirect_url 의 정보를 담고 있다.
3. Resource Owner -> Resource Server
-
링크 클릭 시 url 쿼리 및 파람을 통해 해당 서버로 Client_id, 필요한 기능(scope), redirect_url이 전송
-
Resource Server는 Resource Owner의 현재 로그인 유무 판단
4. Resource Server -> Resource Owner
- 로그인이 안되어 있다면 로그인 화면을 제공
5. Resource Server
-
로그인이 정상적으로 되었다면 해당 사용자의 id, password를 통해 해당 Resource Owner가 누구인지 파악
-
전달받은 url 쿼리, 파람을 통해 Client_id, redirect_url가 Resource Server가 가지고 있는 Client_id, redirect_url과 동일한지 체크
6.Resource Server -> Resource Owner
- 해당 기능(Scope) 권한을 Client에게 부여할 것인지를 확인하는 메세지 전송
7. Resource Owner -> Resource Server
- 허용했을 시 허용했다는 정보 전송
8. Resource Server
- 해당 유저 id가 Scope(기능)에 대한 작업을 허용 했다는 정보를 저장
9. Resource Server -> Resource Client
- Resource Server가 redirection url에 authorization code(임시 비밀번호)를 담아 Resource Client를
redirection시켜줌
즉 클라이언트는 https://client/callback?code=3주소로 이동하게 되며 authorization code(임시 비밀번호)를 Client에 제공해준다.
📣 리다이렉션(Redirection) 방법
Location: https://client/callback?code=3와 같이 header에 Location: <url주소> 를 적어주게 되면 해당 주소로 redirection 된다.
10. Resource Owner -> Client
- Resource Server의 redirection으로 Client에 해당 url 요청
11. Client -> Resource Server
- 전달받은 임시 비밀번호(
authorization code)와 함께
추가적인 설정(grant_type...),redirect url,client_id,client_secret값을 전송한다.
12. Resource Server -> Client
-
기존 가지고 있던(,발급해준) 임시 비밀번호(authorization code), redirect url, client_id, client_secret가 일치하는지 확인한다.
(인증이 확인이 되었다면 authorization code를 지워준다) -
AccessToken을 클라이언트에게 전송해주고 Client는 이를 저장한다.
📣 이 후 Resource Server는 해당 AccessToken를 통해 userId와 허용된 기능에 대한 정보를 알게 된다.
🔎 Refresh Token
- Access Token은 보안상 이유로 토큰 유효 기한이 설정되어 있다. 즉 기한이 만료되면 단계처럼 허용된 기능을 제공해 주지 않는다.
그렇게 되면 사용자는 위 일련의 과정을 다시 한 번 거쳐야 소모값이 발생하기 때문에 이를 방지하고자 Access Token, Refresh Token을 동시에 발급해 줄 수 있다.
Access Token의 기한이 만료되었을 때, Client는 Refrsh Token을 통해 Authorization Server에 보내주게 되고 새로운 Access Token을 발급받을 수 있다.
즉, Refresh Token만 가지고 있다면 위 일련의 과정을 거치지 않고 바로 Access Token을 발급받을 수 있다.
🙏🏻 출처
