OAuth 2.0 권한부여 유형

OAuth 2.0 Grant Type 개요

권한 부여 유형

권한부여 = 클라이언트가 사용자를 대신해서 사용자의 승인하에 인가서버로부터 권한을 부여 받는것을 의미

1. Authorization Code Grant Type = 백 채널에서 동작하는 가장 안전한 유형 , keycloak에서 실습한 방법

2. Implicit Grant Type = 프론트 채널에서 동작함 , 탈취위험이 높음 , deprecated

3. Resoucre Owner Password Credentials Grant Type = 사용자 비번으로 직접 접근 시도 , 위험함

4. Client Credentials Grant Type = client id , client secret만으로 권한이 부여됨 (user가 필요없음)
화면이 없는 서버 앱에서 사용함 
client 가 user 그 자체임

5. Refresh Token Grant Type = 새 access token을 받아올수 있도록 하는 부가기능

6. PKCE-enhanced Authorization Code Grant Type = proof key code exchange , authorization_code의 강화타입이다.
authorization_code를 받아오는 요청을 보낼때 Header에 어떤 해시된 값을 전달한다.
auth server는 해시된 값을 가지고 있다가 access token 요청을 client가 보낼때 해시 되기전의 값과 해싱 알고리즘을 보낸다.
이를 auth server에서 비교를 해보고 access token을 전달해준다.

 

SPA = 브라우저를 통해 돌아가는 js 기반 앱 -> 브라우저에 따라 전략이 다르게 지원된다.
네이티브 = 모바일에서 돌아가는 앱 

 

매개변수 용어 

client_id = 인가 서버(auth server)에 등록된 client에 대해 생성된 고유키

client_secret = 인가서버에 등록된 특정 client의 client_id 에 대해 생성된 password

response_type = 앱이 권한 부여 코드흐름 시작하고 있음을 인가서버에 알려준다. 
code ,token ,id_token 이 있다. 

grant_type = 위에 나온 권한부여유형 을 알려주는것 
authorization_code , password , client_credentials, refresh_token 

redirect_uri = user 가 client을 성공적으로 승인하면 auth server 가 user 다시 client app 으로 redirection을 할때 쓰이는 주소이다.
초기 권한 부여 요청(authorization_code받아올떄) 에 redirect_uri 를 명시했으면 access token 요청시에도 명시해줘야한다. 
access token 요청의 redirect_uri 는 authorization_code 를 생성할 때 사용된 redirect_uri 와 정확히 일치해야한다. 불일치하면 auth server는 요청을 거부한다.
중간에 (access token 요청) client_id, secret 을 가로 채서 해커가 요청을 보내면 authorization_code 요청때 보낸 redirect uri와 다를것임으로 이러한 보안요소를 강화한것이다.

scope = client가 user의 resource의 접근을 제한하기 위해서 존재한다.

state = client 가 임의의 문자열을 요청에 포함하고 ,  user 가 client를 승인한후 auth server로부터 동일한 값이 반환되는 지 확인해야한다. authorization_code , access token 요청 둘다 사용될 수 있다.
CSRF 공격을 방지하는데 사용함

---

Authorization Code  Grant Type - 권한 부여 코드 승인 방식

---

Implicit Grant

backchannel을 사용하지 않으므로 refersh token을 사용하지 못한다. 
토큰이 만료되면 매번 새로운 access token을 얻어와야한다.

---

Resource Owner Passwrod Credentials Grant

client앱이 user의 id,pw 를 access token으로 교환할 떄 사용됨으로 타사 앱이 이권한을 사용하도록 허용해서는 안되고
고도의 신뢰할 자사 앱에서만 사용해야 한다.

사용자의 id ,pw 를 밖으로 노출 시키면 안되기 떄문에 back channel 에서 주고 받는다.

---

Client Credentials Grant

앱이 리소스 소유자인 동시에 클라이언트의 역할을 한다.

서버 대 서버간의 통신에서 사용하며 IOT 장비 앱과의 통신을 위한 인증으로 사용함

Client Id 와 Client Secret 을 통해 액세스 토큰을 바로 발급 받기 떄문에 Refresh Token을 제공하지 않는다.

---

Refresh Token Grant

access token 이 발급될떄 함께 제공되는 토큰이다. refresh token 이 유효하면 인증과정을 첨부터 반복하지 않아도 access token을 다시 준다. 다시 받으면 새로운 refresh token을 주니 , 한번 만 사용이 가능하다.

---

PKCE-enhanced Authorization Code Grant Type

code 교환 을 위한 증명 키로서 CSRF 및 권한부여코드 삽입 공격을 방지하기 위한 Authorization Code Grant Flow 확장 버전이다.

code 요청시 Code Verifer (hashed = Code Challenge) 를 추가로전달해서 Authorization Code Grant Flow 에서 code가 탈취당했을 때 Access token 을 발급하지 못하도록 차단한다.

Code Verifier를 해싱하면 Code Challenge , 해싱하는 알고리즘을 Code Challenge Method

code가 일치하더라도 code_verifier를 해싱한 값이 authorization_code요청에서 받았던 해싱값과 일치하지 않으면 access token을 주지 않는다.

 

 

https://www.inflearn.com/course/%EC%A0%95%EC%88%98%EC%9B%90-%EC%8A%A4%ED%94%84%EB%A7%81-%EC%8B%9C%ED%81%90%EB%A6%AC%ED%8B%B0/dashboard

스프링 시큐리티 OAuth2 - Spring Boot 기반으로 개발하는 Spring Security OAuth2 - 인프런 | 강의