OAuth Protocol Flow 부분과 디테일한 부분을 조금 더 공부하고 싶었다. 개념이나 등장배경, 프로토콜 주체 등은 이전 게시물에 있다. 내가 만든 시퀀스 다이어그램과 함께 공부해보려한다.

---

🔼 직접 만들어본 시퀀스 다이어그램.

OAuth(Open Authorization) Flow

사용자의 정보에 OAuth에 따라 접근하는 과정을 알아보려한다.

새로운 커뮤니티 서비스를 구축하는데 소셜 로그인 기능을 구현하려고 한다. 사용자에게 이름과 비밀번호 등을 입력 받는 대신 서비스 제공자에 저장된 사용자의 정보를 받아올 것이다.

Authorization Server(서비스 제공자)에 Client 등록

• 서비스 제공자는 페이스북, 구글, 카카오 등, Client는 우리가 제작하는 웹 애플리케이션
• Client(웹 애플리케이션)가 Resource Server를 이용하기 위해서는 자신의 서비스를 등록함으로써 사전 승인을 받아야 함.
• 자신의 신원을 등록하는 과정
• 서비스 제공자에 계정을 만든 후에 사용 등록을 하면 Client별로 고유 식별 Client ID와 Secret Key가 생성됨.
  

Client ID

클라이언트 웹 어플리케이션을 구별할 수 있는 식별자이며, 노출해도 무방함.

Client Secret

Client ID에 대한 비밀키, 절대 노출해서는 안됨.

Redirect URI 등록

Authorized Redirect URL이라고도 함.
Authorization Code를 전달받을 리다이렉트 주소.
사용자(Resource Owner)가 Google 등 외부 서비스를 통해 인증을 마치면 클라이언트를 명시된 주소로 리다이렉트 시키는데, 이때 Query String으로 특별한 코드가 함께 전달된다. 클라이언트는 해당 코드와 클라이언트 ID 및 클라이언트 비밀키를 Resource Server로 보내 그 자원을 사용할 수 있는 Access Token을 발급 받음. 등록되지 않은 리다이렉트 URL을 사용하는 경우 인증을 거부함.

Resource Owner의 승인

• Resource Owner가 회원가입 페이지로 소셜 로그인을 요청
• 요청과 동시에 클라이언트 페이지에서 서비스 제공자에게 권한 부여를 위해 Resource Owner의 승인을 요청
• 서비스 제공자가 가진 두가지 서버
  • 인증 및 권한 부여를 담당하는 Authoriation Server(인증 서버)
  • 사용자의 데이터를 관리하는 Resource Server (자원 서버)
• 권한 인증 요청시 파라미터로 넘기는 값
  • 처음에 등록한 클라이언트 ID
  • 사용할 리소스의 범위를 나타내는 Scope
  • Resource Owner의 리소스 사용 승인시 임시 토큰인 Authorization Code를 전달할 Reridect URL

ex: Client Id가 choco1234, 접근할 정보가 email, name, redirect url은 /myservice/auth/success일 경우
쿼리 스트링으로 나타냈을 때
https://auth.google.com/profile?clientId=choco1234&scope=email,name&redirect_url=/myservice/auth/success가 된다.

이후 Authorization Server는 사용자가 로그인하여 리소스 사용을 승인할 수 있는 페이지를 제공한다.

사용자는 Resource Server에 접속하여 로그인을 수행한다. 로그인이 완료되면 Resource Server는 Query String으로 넘어온 파라미터들을 통해 Client를 검사한다.

• 파라미터로 전달된 클라이언트 ID와 동일한 ID값이 존재하는지 확인
• 해당 클라이언트 ID에 해당하는 Redirect URL이 파라미터로 전달된 Redirect URL과 같은지 확인.

검증이 마무리 되면 Resource Server는 Resource Owner에게 다음과 같은 질의를 보낸다.

명시한 Scope에 해당하는 권한을 Client에게 정말로 부여할 것인가?

허용한다면 최종적으로 Resource Owner가 Resource Server에게 Client의 접근을 승인하게 됨.

Resource Server의 승인

Authorization Code

• Resource Owner의 승인이 마무리 되면 명시면 Redirect URL로 클라이언트를 리다이렉트 시킨다.
• Resource Server는 Client가 자신의 자원을 사용할 수 있는 Access Token을 발행받기 위한, 임시 암호인 Authorization Code 부여.

• Query String으로 들어온 code가 바로 Authorization Code이다.
• 클라이언트는 ID와 비밀키 및 Code를 Resource Owner를 거치지 않고 Resource Server에 직접 전달한다.

Access Token

• Resource Server는 정보를 검사한 다음, 유효한 요청이라면 Access Token을 발급한다.

• 클라이언트는 해당 토큰을 서버에 저장해두고, Resource Server의 자원을 사용하기 위한 API 호출시 해당 토큰을 헤더에 담아 보냄.

API 호출

이후 Access Token을 헤더에 담아 해당 API를 호출하면 해당 계정과 연동된 Resource Server의 풍부한 자원 및 기능들을 내가 만든 웹 애플리케이션에서 사용할 수 있다.

Refresh Token

Refresh Token의 발급 여부와 방법 및 갱신 주기 등은 OAuth를 제공하는 Resource Server마다 상이함.

Access Token은 만료 기간이 있고, 만료된 토큰으로 API 요청을 햐면 401 error가 발생함. 재발급을 받을 때마다 서비스 이용자가 재로그인 하는 것은 다소 번거롭다. 그렇기 때문에 보통 Resource Server는 Access Token을 발급할 때 Refresh Token을 함께 발급한다.
Client는 두 토큰을 모두 저장해주고 Resource Server의 API를 호출할 때 Access Token을 사용하다가, 만료되어 401 에러 발생시 Client는 보관 중이던 Refresh Token을 보내 새로운 토큰을 발급받게 됨.

---

참조 ✅

• OAuth 개념 및 동작 방식 이해하기
• OAuth 프로토콜의 이해와 활용 2 - OAuth란 무엇인가?
• Redirect URI