OAuth 동작 원리
이전 포스팅에 이어서 OAuth의 동작원리를 알아보자.
자, 다시 이해관계자들을 간단하게 살펴보자.
Client: 내가 만든 웹사이트
Auth server: Github
Resource server: 역시 Github
Resource owner: 우리 웹사이트를 이용하려는 사용자
쉽게 설명하기 위해서
Client는 우리로, Auth와 Resource server는 깃헙으로, Resource owner는 사용자라고 하겠다.
등록
Client는 우리가 만든 웹사이트라고 했다.
우리 웹사이트의 서비스를 이용하려는 사용자의 정보를
Github에서 얻으려면 먼저 Github Auth server에 등록해야 한다.
등록에 필요한 것은 일반적으로 다음과 같다.
- Client id
- Client secret
- Authorized redirect URI
깃헙의 예시를 가져왔다.
client id와 secret은 깃헙의 Oauth 접근을 위한 '회원등록'과도 같다.
우리 웹사이트를 식별하기 위한 용도이다.
가려져 있는 부분은 무의미한 문자열이 있다.
물론 내가 생성하지 않고 깃헙으로부터 받은 값이다.
Authorized redirect URI은 나중에 깃헙으로부터 토큰(통행증)을 얻기 위한
과정에서 필요로한다고 이해하자.
참고로 깃헙에서 위와 같이 진행하려면
settings -> developer settings -> OAuth Apps에서 확인할 수 있다.
등록 이후
Github에 나의 웹 앱을 등록했다.
이제 웹 사이트에서 사용자에게 OAuth2.0를 통해 회원으로 받을 수 있다.
사용자가 아래의 OAuth 이미지 링크를 누르면
깃허브에 로그인이 되어있는 지를 확인한다.
로그인을 하면 다음처럼 다른 사이트에 인증을 해도 괜찮냐는 페이지가 나온다.
만약 우리가 기본 정보 외에 추가적인 정보를 받을 수 있다고
깃허브에 설정했다면 다른 항목에 대해서도 조회할 수 있는
권한을 줘도 괜찮냐고 다시 물어본다.
이 과정까지 마치고 나면 깃허브에서 유저에게
Authorization code
을 응답하고 우리가 설정했던 redirect uri로 보낸다.
이 Authorization code를 다시 우리에게 사용자가 보낸다.
우리는 이 코드를 깃허브에 보냄으로
깃허브가 자신이 보냈던 코드와 비교하여
동의한 사용자로부터 받았음을 알 수 있다.
만약 이렇게 진행하지 않았다면
우리가 깃허브에게
"유저에게 동의받았어"
라고 해도 깃허브는 알 수 없다.
이렇게해서 우리는 깃허브로부터 토큰을 받을 수 있다.
토큰에 유효한 시간이 적혀있어
이 시간동안 우리는 유저에게 동의받은 권한으로
서비스에 필요한 정보를 조회할 수 있다.
만약 유효 시간이 넘어갔다면 refresh token으로 새롭게 갱신한다.
Spring Security
스프링을 통한 자세한 구현은 아래 포스팅을 참고하자.
'컴퓨터과학' 카테고리의 다른 글
리눅스 (0) | 2023.09.17 |
---|---|
OIDC, OpenID Connect 누구냐 넌 (0) | 2023.07.20 |
OAuth, 간단하게 알아보자 (0) | 2023.07.07 |
도커란? (0) | 2023.06.26 |
HTTP 헤더란? (0) | 2023.06.11 |