OAuth 2.0 관련 용어 공부

인가(Authorization)

확인된 사용자가 특정 자원에 접근할 권한이 있는지 확인 (권한 확인)

 

인증(Authentication)

사용자가 누구인지 확인 (로그인)

따라서 일반적인 순서: Authentication → Authorization

 

인증 서버(Authorization server)

OAuth 2.0 프레임워크의 구성요소로, 클라이언트가 인증 및 인가에 성공하면 Access Token을 발급한다.

 

Bearer 인증

OAuth 2.0 프레임워크에서 사용하는 토큰 인증 방식. HTTP 통신시 Header에 “Authorization: Bearer ”과 같은 형식으로 사용한다. Basic 인증방식만으로는 사용자의 권한을 정교하게 제어할 수 없기 때문에 등장했다. 형식은 *불투명한(Opaque) 문자열일수도 있고, JWT일수도 있다. Bearer 토큰에는 서버가 클라이언트의 권한을 확인할 수 있는 메타데이터가 포함되어 있어야한다. 이때문에 서버는 토큰을 발급만하고 보관할 필요가 없고, 빠르게 토큰 검증을 할 수 있다.

 

Basic 인증

가장 기본적인 인증방식. HTTP 통신시 Header에 “Authorization: Basic base64(:)”와 같은 형식으로 사용한다. 사용자 ID와 비밀번호를 base64로 인코딩한 형식이다. base64는 쉽게 디코딩가능하기 때문에 HTTPS, SSL/TLS로 통신해야 안전하다.

 

불투명 토큰(Opaque token)

클라이언트에게는 의미가 없지만 서버의 데이터베이스에서 권한 데이터를 조회하는 참조 키 역할을 하는 무작위의 고유한 문자열이다. 다음은 불투명 토큰의 예시이다: M-oxIny1RfaFbmjMX54L8Pl-KQEPeQvF6awzjWFA3iq

JWT와는 달리 자체적으로 정보를 포함하지 않으므로, 서버는 백엔드 데이터베이스를 조회해서 이 토큰이 가진 권한 데이터를 별도로 가져오는 절차를 거쳐야한다.

 

PKCE (Profile Key for Code Exchange)

암시적 흐름(Implicit Flow)은 권한 부여서버가 바로 토큰을 반환하는 방법이다. 하지만 OAuth 2.1 부터는 공식적으로 사용이 중단되었는데, URL에 Access Token이 노출되고, Refresh Token을 사용할 수 없어서 클라이언트가 안전하지 않은 방법으로 Access Token을 저장할 수 있다는 보안 문제가 있었기 때문이다. 이제 클라이언트 전용 앱에서는 권한 부여 코드 플로우(Authorization Code Flow) + PKCE를 사용해야한다.

 

PKCE는 인증 코드 가로채기 공격을 방지하여 인증 플로우를 시작한 클라이언트만이 토큰 교환에 성공할 수 있도록 보장한다.

 

*PKCE 인증 코드 흐름:

1. 클라이언트가 43~128자의 랜덤 URL 안전 문자열로 코드 검증자(Code Verifier)를 생성한다.
2. 클라이언트는 코드 검증자를 SHA-256과 같은 암호화 해시 함수로 해싱하고, 해시를 Base64 문자열로 인코딩한다. 이렇게 생성된 문자열을 코드 챌린지(Code Challenge)라고 한다.
3. 클라이언트가 인증요청시 코드 챌린지를 포함한다. code_challenge_method 매개변수는 코드 챌린지를 생성하는데 사용된 해싱 알고리즘 (e. g., S256 for SHA-256)을 지정한 것이다.

GET /authorize?response_type=code
...
&code_challenge=YOUR_CODE_CHALLENGE
&code_challenge_method=S256

 

4. 클라이언트는 코드 검증자를 나중에 사용하기 위해 어딘가 저장하고, 인증 코드(Authorization Code)를 수신하면 토큰 요청을 코드 검증자와 함께 인증 서버로 보내야한다.

POST /token
...
&code=YOUR_AUTHORIZATION_CODE
...
&code_verifier=YOUR_CODE_VERIFIER

 

5. 인증서버는 코드 검증자와 코드 챌린지를 검증하여 클라이언트가 동일한 플로우에서 진행하고 있다는 것을 확인한다. 검증이 실패하면 인증 서버는 토큰 요청을 거절하면된다.

 

 

참고 자료

https://docs.tosspayments.com/resources/glossary/bearer-auth

https://auth-wiki.logto.io/ko