Spring Security ‐ OAuth 2.0 권한부여 유형 - dnwls16071/Backend_Summary GitHub Wiki

📚 OAuth 2.0 Grant Type

  • 권한 부여란 클라이언트가 사용자를 대신해서 사용자의 승인 하에 인가서버로부터 권한을 부여받는 것을 말한다.
  • OAuth 2.0 메커니즘은 아래와 같은 권한 부여 유형들을 지원하고 있으며 일부는 사장되었다.

1. Authorization Code Grant Type

  • 권한 코드 부여 타입, 서버 사이드 애플리케이션, 보안에 가장 안전한 유형

2. Implict Grant Type(Deprecated)

  • 암시적 부여 타입, 공개 클라이언트 애플리케이션, 보안에 취약

3. Resource Owner Password Credentials Grant Type(Deprecated)

  • 리소스 사용자 비밀번호 자격 증명 부여 타입, 서버 애플리케이션, 보안에 취약

4. Client Credentials Grant Type

  • 클라이언트 자격 증명 권한 부여 타입, UI or 화면이 없는 서버 애플리케이션

5. Refresh Token Grant Type

  • 갱신 토큰 부여 타입, Authorization Code, Resource Owner Password Type에서 지원됨

6. PKCE - enhanced Authorization Code Grant Type

  • PKCE 권한 코드 부여 타입, 서버 사이드 애플리케이션, 공개 클라이언트 애플리케이션

📒관련 매개변수 정리

1. client_id

  • 인가 서버에 등록된 클라이언트에 대해 생성된 고유 키

2. client_secret

  • 인가 서버에 등록된 특정 클라이언트의 client_id에 대해 생성된 비밀 값

3. response_type

  • 애플리케이션이 권한 부여 코드 흐름을 시작하고 있음을 인증 서버에 알려준다.
  • code, token, id_token이 있으며 token, id_token은 implict 권한 부여 유형에서 지원해야 한다.
  • 서버가 쿼리 문자열에 인증 코드(code), 토큰(token, id_token) 등을 반환

4. grant_type

  • 권한 부여 타입 지정 - authorization_code, password, client_credentials, refresh_token

5. redirect_uri

  • 사용자가 응용 프로그램을 성공적으로 승인하면 권한 부여 서버가 사용자를 다시 응용 프로그램으로 리디렉션한다.
  • redirect_uri가 초기 권한 부여 요청에ㅜ 포함된 경우 서비스는 토큰 요청에서도 이를 요구해야 한다.
  • 토큰 요청의 redirect_uri는 인증 코드를 생성할 때 사용된 redirect_uri와 정확히 일치해야 한다. 그렇지 않으면 서비스는 요청을 거부해야 한다.

6. scope

  • 애플리케이션이 사용자 데이터에 접근하는 것을 제한하기 위해 사용된다.
  • 사용자에 의해 특정 스코프로 제한된 권한 인가권을 발행함으로써 데이터 접근을 제한한다.

7. state

  • 응용 프로그램은 임의의 문자열을 생성하고 요청에 포함하고 사용자가 앱을 승인한 후 서버로부터 동일한 값이 반환되는지를 확인해야 한다.
  • 이것은 CSRF 공격을 방지하는 데 사용된다.

📚 Authorization Code Grant Type

  • 사용자가 애플리케이션을 승인하면 인가 서버는 Redirect URI로 임시 코드를 담아 애플리케이션으로 다시 리다이렉트한다.
  • 애플리케이션은 해당 임시 코드를 인가 서버로 전달하고 액세스 토큰으로 교환한다.
  • 애플리케이션이 액세스 토큰을 요청할 때 해당 요청을 클라이언트 암호로 인증할 수 있으므로 공격자가 인증 코드를 가로채서 스스로 사용할 위험이 줄어든다.
  • 액세스 토큰이 사용자 또는 브라우저에 표시되지 않고 애플리케이션에 다시 전달하는 가장 안전한 방법으로 토큰이 다른 사람에게 노출될 위험이 줄어든다.

권한 부여 코드 요청 시 매개변수

  • response_type=code(필수)
  • client_id(필수)
  • redirect_uri(선택)
  • scope(선택)
  • state(선택)

액세스 토큰 교환 요청 시 매개변수

  • grant_type=authorization_code(필수)
  • code(필수)
  • redirect_uri(필수)
  • client_id(필수)
  • client_secret(필수)

📚 Implicit Grant Type

  • 클라이언트에서 javascript 및 HTML 소스 코드를 다운로드한 후 브라우저는 서비스에 직접 API 요청을 한다.
  • 코드 교환 단계를 건너뛰고 대신 액세스 토큰이 쿼리 문자열 조각으로 클라이언트에 즉시 반환된다.
  • 이 유형은 back channel이 없으므로 refresh token을 사용하지 못한다.
  • 토큰 만료 시 애플리케이션이 새로운 access token을 얻으려면 다시 OAuth 승인 과정을 거쳐야 한다.

권한 부여 승인 요청 시 매개변수

  • response_type=token(필수), id_token
  • client_id(필수)
  • redirect_uri(필수)
  • scope(선택)
  • state(선택)

📚 Resource Owner Password Credentials Grant Type

  • 애플리케이션이 사용자 이름과 암호를 액세스 토큰으로 교환할 때 사용된다.
  • 타사 애플리케이션이 이 권한을 사용하도록 허용해선 안되고 고도의 신뢰할 자사 애플리케이션에서만 사용해야 한다.

권한 부여 승인 요청 시 매개변수

  • grant_type=password(필수)
  • username(필수)
  • password(필수)
  • client_id(필수)
  • client_secret(필수)
  • scope(선택)

📚 Client Credentials Grant Type

  • 애플리케이션이 리소스 사용자인 동시에 클라이언트 역할을 한다.
  • 리소스 소유자에게 권한 위임을 받아 리소스에 접근하는 것이 아니라 자기 자신이 애플리케이션을 사용할 목적으로 사용하는 것
  • 서버 - 서버 간 통신에서 사용할 수 있으며 IoT 장비 애플리케이션과의 통신을 위한 인증으로도 사용이 가능하다.
  • client ID와 client Secret을 통해 액세스 토큰을 바로 발급받을 수 있기 때문에 Refresh Token은 제공하지 않는다.
  • Client 정보를 기반으로 하기 때문에 사용자 정보는 제공하지 않는다.

권한 부여 승인 요청 시 매개변수

  • grant_type=client_credentials(필수)
  • client_id(필수)
  • client_secret(필수)
  • scope(선택사항)

📚 Refresh Token Grant Type

  • 액세스 토큰이 발급될 때 함께 제공되는 토큰으로 액세스 토큰이 만료되더라도 함께 발급받았던 리프레시 토큰이 유효하다면 인증 과정을 처음부터 반복하지 않아도 액세스 토큰을 재발급 받을 수 있다.

권한 부여 승인 요청 시 매개변수

  • grant_type=refresh_token(필수)
  • refresh_token
  • client_secret(필수)
  • client_id(필수)

📚 PKCE - enhanced Authorization Code Grant Type

  • 코드 교환을 위한 증명 키로서 CSRF 및 권한 부여 코드 삽입 공격 방지를 위한 Authorization Code Grant Flow의 확장버전이다.
  • 권한 부여 코드 요청 시 Code Verifier와 Code Challenge를 추가해 만약 Authorization Code Grant Flow에서 Authorization Code가 탈취당했을 때, Access Token을 발급하지 못하도록 차단한다.
  • PKCE는 원래 모바일 앱에서 Authorization Code Grant Flow를 보호하도록 설계되었으며 나중에 단일 페이지 앱에서도 사용하도록 권장되며 모든 유형의 OAuth2 클라이언트, 심지어 클라이언트 암호를 사용하는 웹 서버에서 실행되는 앱에서도 유용하다.

코드 생성

  1. Code Verifier
  • 권한 부여 코드 요청 전에 앱이 원래 생성한 PKCE 요청에 대한 코드 검증기
  • 48 ~ 128 글자 수를 가진 무작위 문자열
  • A-Z a-z 0-9 등의 ASCII 문자들로만 구성
  1. Code Challenge
  • 선택한 Hash 알고리즘으로 Code Verifier를 Hashing한 후 Base64 인코딩을 한 값
  1. Code Challenge Method
  • plain - Code Verifier가 특정 알고리즘을 사용하지 않도록 설정
  • S256 - Code Verifier가 해시 알고리즘을 사용하도록 설정

Code Challange Method 검증

  1. 권한 부여 코드 흐름에 있어 인가서버는 code_verifier를 검증하기 위해 code_challenge_method 을 이미 알고 있어야 한다.
  2. 토큰 교환시 code_challenge_method가 plain 이면 인가서버는 전달된 code_verifier와 보관하고 있는 code_challenge 문자열과 단순히 일치하는지 확인만 하면 된다.
  3. code_challenge_method가 S256이면 인가서버는 전달된 code_verifier를 가져와서 동일한 S256 해시 메소드를 사용하여 변환한 다음 보관된 code_challenge 문자열과 비교해서 일치 여부를 판단한다.