깃허브, 네이버, 카카오등을 통해 우리는 소셜 로그인을 만들 수 있다. 나의 서비스와 이들은 서로에 대해서는 사실 모른다고 표현할 수 있고 그들 가운데 oauth라는 표준 인터페이스 역할을 하는 것이 있다. 이것에 의하여 묶여 소셜 로그인이 된다. oauth를 활용하면 우리가 만든 서비스가 그들의 서비스와 상호작용 할 수 있게 된다.
우리가 만든 서비스는 ID나 PW가 아닌 access Token이라는 것을 oauth를 통해 획득하고 그 토큰을 활용하여 다른 서비스에 접근해서 데이터를 가져오고 생성하고 수정하는 등의 작업이 가능하다. 이 access Token이 사용자를 식별할 수 있는 것이다.
이 때 Their을 담당하는 다른 서비스를 Resoure Server, 그리고 우리가 만든 서비스(mine)를 Client, 사용자를 Resource Owner 라고 한다.
**참고**
*Authorization Server : Resource Server는 데이터를 가지고 있는 서버이고 Authorization Server는 인증과 관련된 처리를 전담하는 서버이다. 공식 문서에는 이 두가지를 구분해서 보여준다.
Client와 Resoure Server 간 통신을 할 때 서로 Client id, Client Sercret의 정보를 가진다. 사용자가 B,C의 두가지 기능을 사용할 예정이라면 소셜 로그인 버튼은 그림과 같이 client id, scope, redirect_url을 포함하여 URL을 생성하여 Resource Server에 보내면 된다. 로그인 상태에서 접근하면 Resouce Server는 Resouce Owner에게 B,C에 대한 기능을 우리가 만든 Client가 사용할 수 있도록 할 것인지 묻는다. 허용을 한다면 Resouce Server는 동의한 정보를 저장하게 된고 Client 입장에서는 Resoure Owner 즉 사용자에 대한 승인을 완료한 것이다.
그렇다고 Resoure Server는 바로 access Token을 발급하지 않는다. Resoure Server의 승인 작업을 해야한다.
Resoure Server는 authorization code라는 임시 비밀번호를 Resource Owner에게 전송한다.
Resource Owner는 은밀하게 Resoure Server가 제공해준 https://client/callback?code=3으로 이동을 하게 된다. code=3이라는 것에 대해서 Client는 알게 된다. 이렇게 되면 access Token을 발급하기 전 상태까지 온 것이다.
Client는 Client id, Client Secret, redirect_url, authorization code를 Resouce Server에게 요청한다. Resource Server는 기존의 값들과 모두 일치하는지 비교하고 access Token을 발급하여 Client에게 전달한다. oauth의 목적은 이 access Token의 발급이다. 이제 Client는 access Token을 사용하여 user id =1 에 대한 사용자의 B,C 기능이 열려있다.
access Token의 수명이 끝났을 때를 다시 발급받기 위해 사용자에게 다시 묻는 것은 힘든일이다.
이것에 대비하여 Refresh Token 이라는 것을 같이 활용하여 이러한 불편함을 없앨 수 있다.
**참고**
Oauth2의 구조
1. 클라이언트에서 소셜 로그인 요청
2. 백엔드로 GET /oauth2/authorization/{provider-id}? redirect_uri=http://localhost:3000/oauth/redirect
으로 OAuth 인가 요청
3. Provider 별로 Authorization Code 인증을 할 수 있도록 리다이렉트
Redirect : GET https://oauth.provider.com/oauth2.0/authorize?…
4. 리다이렉트 화면에서 provider 서비스에 로그인
5. 로그인이 완료된 후, Athorization server로부터 백엔드로 Authorization 코드 응답
6. 백엔드에서 인가 코드를 이용하여 Authorization Server에 엑세스 토큰 요청
7. 엑세스 토큰 획득
8. 엑세스 토큰을 이용하여 Resource Server에 유저 데이터 요청
9. 획득한 유저 데이터를 DB에 저장 후, JWT 엑세스 토큰과 리프레시 토큰을 생성
10. 리프레시 토큰은 수정 불가능한 쿠키에 저장하고, 엑세스 토큰은 프로트엔드 리다이렉트 URI 에 쿼리스트링에 토큰을 담아 리다이렉트 (Redirect: GET http://localhost:3000/oauth/redirect?token={jwt-token})
11. 이후 사용자 인증 과정
Oauth2의 역할
출처: 생활코딩 WEB2- OAuth 2.0
https://www.youtube.com/watch?v=hm2r6LtUbk8&list=PLuHgQVnccGMA4guyznDlykFJh28_R08Q-
'IT' 카테고리의 다른 글
| Spring Security User(UserDetail) 커스텀 (0) | 2022.09.26 |
|---|---|
| 스프링부트 카카오 소셜 로그인 1(셋팅 및 설정 작업) (0) | 2022.09.25 |
| 젠킨스(jenkins)로 스프링부트 자동화 3(파이프라인) (0) | 2022.09.22 |
| 젠킨스(jenkins)로 스프링부트 자동화 2(도커, DB 설치, 빌드) (0) | 2022.09.21 |
| 젠킨스(jenkins)로 스프링부트 자동화 1(jenkins에서 jdk-17설치) (1) | 2022.09.21 |
