40. Authentication - OAuth 2.0

libertegrace.tistory.com/entry/8-Social-Login-Oct-30-2020-%ED%9A%8C%EA%B3%A0

여기에 아래의 내용을 더 자세하고 보충하여 정리하였습니다.  

---

1. OAuth 소개

앞서 회원가입/로그인/로그아웃 등을 express와 session 개념을 사용해서 구현해보았다. 

그러나 우리가 편하게 사용하고 있는 소셜로그인( 카카오 아이디로 로그인, 구글 아이디로 로그인 등.. ) 방법은 어떻게 작동하는 것일까?

 

이 기능을 사용하기 위해선 나, 내가 사용하고 싶은 앱/웹, 로그인을 중개해주는 카카오, 구글 같은 소셜이 관여할 것이다. 만약 '소셜 로그인' 이라는 것이 진짜 '내가 사용하고 싶은 앱/웹'과 '로그인을 중개해주는 카카오, 구글 같은 소셜' 사이에서 내 아이디와 비번을 공유하는 거라면?

내 아이디와 비번을 여러 서비스에서 돌려쓴다고? 그리고 이게 만약 유출된다면? 이런 불안정성은 이 3 관여대상들 모두에게 매우 부담이 되는 것이다. 

그래서 등장한 것이 OAuth 이다. 이를 이용하면 '내가 사용하고 싶은 앱/웹'과 '로그인을 중개해주는 카카오, 구글 같은 소셜'간의 서비스를 안전하게 상호작용하며 사용할 수 있다.

 

어떻게??

'카카오, 구글 같은 소셜'이 '내가 사용하고 싶은 앱/웹'에게 '나'의 아이디와 비번을 그대로 제공하는 것이 아니라 AccessToken의 형태로 발급하여 전달한다.

Access Token의 장점이 뭐길래?

• 반복된 말이지만, 일단 쌩판 동일한 아이디, 비번을 제공하는게 아니고
• '카카오 구글 같은 소셜'의 모든 기능이 아니라 그 중 '내가 사용하고 싶은 웹/앱' 에 꼭 필요한 기능만 부분적으로 접근허용할 수 있다. 

그래서 Social Login 기능을 구현해보기 앞서 OAuth를 소개하고 시작부터~Access Token 발급하는 OAuth를 사용하는 절차에 대해서 정리해 보고자 한다. (갓 생활코딩 강의를 들으며 정리한 것임☞☜)

2. 역할 및 용어

•  Resource Owner  = 내서비스를 사용할 사용자
•  Resource Server = 리소스 제공자 (구글, 페이스북) : 데이터를 가지고 있는 서버
  (Authorizationn Server = 인증과 관련된 처리를 전담하는 서버 ; 이지만 이를 Resource Server에 포함시켜서 정리해볼 것이다. )
•  Client  = 서드 파티 서비스 (내서비스, 내가 구현할 어플리케이션)

3. OAuth를 사용하는 절차

1) Resource Server(의 인증대행서비스)를 사용하기 위해서는 먼저 등록이 필요하다. 

서비스마다 등록하는 방법이 다 다르지만 공통적으로 등록 후에는 Client 와 Resource Server 는 아래 3가지를 공유하게 된다

• Client ID: 내가 구현 할 어플리케이션인 Client  를 식별 할 수 있는 ID
• Client Secret: 내가 구현 할 어플리케이션인 Client를 식별 할 수 있는 PW (절대, 코드에 노출되면 안되는 정보, 보안 이슈 심각)
• Authorized Redirect URL: Resource Server가 권한을 부여하는 과정에서 Authorized Code를 전달해 줄 경로, (' Authorized rediret URIs로 Authorized Code 전달해줘~')

등록의 예시) 

출처: 생활코딩

2) Resource Owner가 Resource Server에게 Client의 접근을 승인하는 과정 

앞의 intro에서 살펴본 것 처럼 Client가 Resource Server의 모든 기능이 아닌 몇 가지 필요한 기능만 사용하면 된다면,

그 일부 기능의 사용에 필요한 인증만 받으면 좋을 것이다.  

1. Resource Owner가 Client에서 Resource Server기능 중 B, C를 사용하려 한다면

Client는 특정 형식의 주소를 가지는 버튼('sign in [해당 Resource Server]' 버튼 같은..)을 제공한다. 

2. Resource Owner가 그 버튼을 누르면 Resource Server는 Resource Owner가 현재 자신의 그 서비스에 현재 로그인 되어 있는지 확인하고 

3-1. => 되어 있다면,  Resource Server는 그 버튼 주소의 client_id 값과 같은 client id값이 있는지를 확인한다. 

3-2. => 되어있지 않다면, 로그인을 하라는 화면을 보여준다. 

      4. --> 있다면, 그 버튼 주소의  redirect__uri와 자신이 가진 redirect URL와 같은지 확인한다. 

            5-1. ---> 같지 않다면, 거기서 끝내버리고

            5-2. ---> 같다면 Resource Owner에게 그 버튼 주소의 scope에 해당하는 권한을 Client에게 허용한는지 확인하는 메세지를 전송

                   6.  ----> Resource Owner가 허용한다고 하면 허용 응답이 Resource Server에게 갈 것이고, 

                            7. ------> Resource Server는 user id:[그 버튼 주소의 client_id 값], scope: [그 버튼 주소의 scope]을 허용의 표시로 저장한다.

출처: 생활코딩

 

 

3) Resource Server이 승인하는 과정

위의 과정에서 Resource Owner의 허락을 획득하였으니, Resource Server가 승인을 해줄 차례이다. 

1. Authorization Code를 Resource Server가 response의 header에 location: https://[redirect URL]?code=[Authorization Code]'이라는 값을 주어 redirect하도록 한다. 

말이 너무 어려운데.. 역시 생활코딩 그림이 짱이닷.

2. 그러면 Resource Owner의 위치는 location에 담긴 주소로 이동하게 됨 (redirect되니까!)

3. 그렇게 Client는 redirect URL 뒤에 params 형태로 담긴 authorization code를 알게 되는 것이다. 

4. 이렇게 Resource Server가 가진 Authorization code를 Client도 가지게 되면, Client는 아래 그림과 같은 형식의 주소로 Resource Server에 직접 접속한다.  

5. 이 Client가 전송한 주소에 있는 Authorization code와 client ID, client secret, redirect URL이 모두 일치하는지를 보고

모두 일치할 때! 그때 !!

6. Access Token을 발급한다! 드디어!!!

 

4) Access Token을 발급받는 과정★

1. Resource Server와 Client는 승인이 다 되었으므로 앞으로 중복 인증을 피하기 위해Authorization code를 지운다. 그리고 Resource Server는 Access Token을 발급했다! 

2. 그리고 발급한 Access Token을 Client에게 응답해준다. 그러면 Client는 이 Accesss Token을 저장할 것이다. 

3. Access Token이 어떻게 활용되는지 보자.

Client가 위의 단계로 생성된 Access Token으로 Resource Server에 접근하면, 

Resource Server은  Access Token을 보고  'user id가 ~~인 사용자의 정보에 대해서 scope ~, ~ .. 을 허용'한다. 

 

이제 Access Token을 활용해서 API를 통해 Resource Server의 리소스를 사용 할 수 있다 :))

 

 

Reference

velog.io/@parkoon/OAuth-%EC%99%84%EB%B2%BD%ED%95%98%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0

OAuth 완벽하게 이해하기

opentutorials.org/course/3405

www.oauth.com/oauth2-servers/getting-ready/