티스토리 뷰

Development/Network

[Network]OAuth 2.0 Workflow

Vagabund.Gni 2022. 9. 28. 14:47
728x90
반응형

지난 글에서 OAuth 2.0에 대한 소개와 대략적인 일처리 흐름 및 용어에 대한 정리를 마쳤다.

 

2022.09.28 - [Development/Network] - [Network]OAuth 2.0

 

[Network]OAuth2.0

OAuth(Open Authorization)는 사용자의 비밀번호 없이도 접근 권한을 받을 수 있는 개방형 표준이다. 구체적으로는 사용자가 사용하는 앱(여기서는 클라이언트라 부른다)은 보안을 위해 인증을 다른 업

gnidinger.tistory.com

이번 글에서는 조금 더 구체적인 OAuth 2.0의 동작 방식과 권한 인증 방식에 대해 알아본다.

 

OAuth 2.0 Workflow

 

지난 글에서도 대략 알아봤듯이 OAuth는 아래와 같은 절차를 따른다.

 

  1. 사용자가 클라이언트에게 로그인 요청 전달
  2. 클라이언트는 서드파티 애플리케이션으로 요청 리다이렉트
  3. 로그인 인증 진행 후 성공
  4. Authorization Server는 인증 결과를 바탕으로 Access Token을 클라이언트에게 발급
  5. Access Token을 사용해 Resource Server에게 요청 전달
  6. Access Token 검증 후 리소스 반환
  7. 클라이언트가 사용자에게 응답 결과 반환

클라이언트가 사용자를 대리해 Access Token을 관리하고 Resource Server에서 응답을 받는 것을 확인할 수 있다.

 

이때 Authorization Server에서 클라이언트로 Access Token이 전달되는 과정에서

 

클라이언트의 환경에 따라 서로 다른 프로토콜을 제공하는데, 이를 Authorization Grant라고 한다.

 

계속해서 알아보자.

 

Athorization Grant

 

권한 부여 방식은 위에서 언급한 대로 클라이언트와 Authorization Server 간에 권한 부여를 주고받는 방식이다.

 

클라이언트 환경에 따라 크게 네 가지 방식을 제공하고 있는데, 하나씩 천천히 알아보자.

 

Authorization Code Grant

 

Authorization Code Grant(권한 부여 코드 방식)는 권한 부여를 위해 자체 생성한 코드를 전달하는 방식으로,

 

위와 같은 상황에서 소셜 로그인 등을 이용해 클라이언트가 사용자를 대리해 서버에 접근할 때 사용하는 방식이다.

 

Refresh Token을 사용할 수 있으며, 가장 일반적이고 많이 사용되는 방식이다.

 

추가로 권한 부여 요청 시 응답 타입(response_type)을 code로 지정하여 요청한다.

 

  1. 사용자가 서비스 요청
  2. 클라이언트가 Authorization Server에 Client ID, Redirect URI, 응답 타입을 담아 Authorization Code 요청
  3. 사용자가 로그인 진행
  4. Authorization Server가 Authorization Code를 Redirect URI를 통해 클라이언트에게 전달
  5. 클라이언트가 Authorization Code를 이용해 Access Token 발급 요청
  6. Access Token 발급
  7. 클라이언트가 Access Token을 이용해 Resource Server에 리소스 요청
  8. 리소스 반환
  9. 완료

 

Implicit Grant

 

Implicit Grant(암묵적 승인 방식)는 별도의 인증 코드 없이 바로 Access Token을 발급하는 방식이다.

 

자격 증명을 안전하게 보관하기 힘든 스크립트 언어를 사용하는 클라이언트에게 최적화된 방식이며,

 

Refresh Token의 사용이 불가능하다.

 

또한 위에서 응답 타입이 code였던 것과 달리 응답 타입을 token으로 지정한다.

 

  1. 사용자가 서비스 요청
  2. 클라이언트가 Authorization Server에 Client ID, Redirect URI, 응답 타입을 담아 접근 권한 요청
  3. 사용자가 로그인 진행
  4. Authorization Server가 로그인 확인 후 Access Token 발급
  5. 클라이언트가 Access Token을 이용해 Resource Server에 리소스 요청
  6. 리소스 반환
  7. 완료

 

Resource Owner Password Credential Grant

 

Resource Owner Password Credential Grant(사용자 자격 증명 승인 방식)은 ID와 비밀번호로 발급받는 방식이다.

 

Refresh Token의 사용이 가능하며, 같은 시스템에서 서비스하는 애플리케이션의 경우만 사용된다.

 

예를 들면 카카오 계정으로 카카오 지도에 로그인하는 경우와 같이 Client, Authorization Server, Resource Server가

 

전부 같은 시스템에 속해 있을 때만 사용이 가능하다는 뜻이다.

 

  1. 사용자가 크리덴셜을 담아 서비스 요청
  2. 클라이언트가 크리덴셜을 이용해 Authorization Token 요청
  3. Authorization Server가 검증 후 Access Token 발급
  4. 클라이언트가 Access Token을 이용해 Resource Server에 리소스 요청
  5. 리소스 반환
  6. 완료

 

Client Credentials Grant

 

Client Credential Grant(클라이언트 자격 증명 승인 방식)는 클라이언트가 관리하는 서버에

 

해당 클라이언트를 위한 접근 권한이 설정되어 있는 경우 사용 가능한 방식이다.

 

Refresh Token의 사용은 불가능하며, 자격 증명을 안전하게 보관할 수 있는 클라이언트에서만 사용되어야 한다.

 

 

반응형
댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/11   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
글 보관함