티스토리 뷰
지난 글에서 OAuth 2.0에 대한 소개와 대략적인 일처리 흐름 및 용어에 대한 정리를 마쳤다.
2022.09.28 - [Development/Network] - [Network]OAuth 2.0
이번 글에서는 조금 더 구체적인 OAuth 2.0의 동작 방식과 권한 인증 방식에 대해 알아본다.
OAuth 2.0 Workflow
지난 글에서도 대략 알아봤듯이 OAuth는 아래와 같은 절차를 따른다.
- 사용자가 클라이언트에게 로그인 요청 전달
- 클라이언트는 서드파티 애플리케이션으로 요청 리다이렉트
- 로그인 인증 진행 후 성공
- Authorization Server는 인증 결과를 바탕으로 Access Token을 클라이언트에게 발급
- Access Token을 사용해 Resource Server에게 요청 전달
- Access Token 검증 후 리소스 반환
- 클라이언트가 사용자에게 응답 결과 반환
클라이언트가 사용자를 대리해 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로 지정하여 요청한다.
- 사용자가 서비스 요청
- 클라이언트가 Authorization Server에 Client ID, Redirect URI, 응답 타입을 담아 Authorization Code 요청
- 사용자가 로그인 진행
- Authorization Server가 Authorization Code를 Redirect URI를 통해 클라이언트에게 전달
- 클라이언트가 Authorization Code를 이용해 Access Token 발급 요청
- Access Token 발급
- 클라이언트가 Access Token을 이용해 Resource Server에 리소스 요청
- 리소스 반환
- 완료
Implicit Grant
Implicit Grant(암묵적 승인 방식)는 별도의 인증 코드 없이 바로 Access Token을 발급하는 방식이다.
자격 증명을 안전하게 보관하기 힘든 스크립트 언어를 사용하는 클라이언트에게 최적화된 방식이며,
Refresh Token의 사용이 불가능하다.
또한 위에서 응답 타입이 code였던 것과 달리 응답 타입을 token으로 지정한다.
- 사용자가 서비스 요청
- 클라이언트가 Authorization Server에 Client ID, Redirect URI, 응답 타입을 담아 접근 권한 요청
- 사용자가 로그인 진행
- Authorization Server가 로그인 확인 후 Access Token 발급
- 클라이언트가 Access Token을 이용해 Resource Server에 리소스 요청
- 리소스 반환
- 완료
Resource Owner Password Credential Grant
Resource Owner Password Credential Grant(사용자 자격 증명 승인 방식)은 ID와 비밀번호로 발급받는 방식이다.
Refresh Token의 사용이 가능하며, 같은 시스템에서 서비스하는 애플리케이션의 경우만 사용된다.
예를 들면 카카오 계정으로 카카오 지도에 로그인하는 경우와 같이 Client, Authorization Server, Resource Server가
전부 같은 시스템에 속해 있을 때만 사용이 가능하다는 뜻이다.
- 사용자가 크리덴셜을 담아 서비스 요청
- 클라이언트가 크리덴셜을 이용해 Authorization Token 요청
- Authorization Server가 검증 후 Access Token 발급
- 클라이언트가 Access Token을 이용해 Resource Server에 리소스 요청
- 리소스 반환
- 완료
Client Credentials Grant
Client Credential Grant(클라이언트 자격 증명 승인 방식)는 클라이언트가 관리하는 서버에
해당 클라이언트를 위한 접근 권한이 설정되어 있는 경우 사용 가능한 방식이다.
Refresh Token의 사용은 불가능하며, 자격 증명을 안전하게 보관할 수 있는 클라이언트에서만 사용되어야 한다.
'Development > Network' 카테고리의 다른 글
[Network]HTTP status Code 요약 (0) | 2023.03.18 |
---|---|
[Network]NGINX 튜토리얼 (1) | 2023.03.07 |
[Network]네트워크 클래스, CIDR(사이더) 라우팅 기법 (2) | 2022.10.11 |
[Network]OAuth 2.0 (0) | 2022.09.28 |
[Network]JWT(JSON Web Token) (0) | 2022.09.23 |
[Network]세션 기반 인증 vs. 토큰 기반 인증 (0) | 2022.09.23 |
- Total
- Today
- Yesterday
- 유럽여행
- 남미
- 리스트
- 여행
- 지지
- 칼이사
- 파이썬
- spring
- 스트림
- 야경
- 중남미
- 기술면접
- 면접 준비
- 동적계획법
- 세계일주
- 세계여행
- a6000
- RX100M5
- 자바
- 백준
- 유럽
- java
- Algorithm
- BOJ
- 맛집
- Python
- 스프링
- Backjoon
- 세모
- 알고리즘
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |