4가지 인증 방식(프로토콜)

OAuth2.0에서 client는 Authorization Server에게 아래 4가지 인증 방식으로 토큰을 요청할 수 있다. 각각의 동작 방식 및 과정에 대해서 살펴보자.

각 프로젝트 상황에 맞게 방식을 적용하면 된다. 이때, 각 승인 방식에서 OAuth의 목적인 AccessToken을 어떻게 발급하고, 사용하냐가 관건이다.

1.Authorization Code Grant(권한 부여 코드 승인 방식)

• 사용하지 않아 이후에 정리 예정

2.Implicit Grant(암묵적 승인 방식)

• 사용하지 않아 이후에 정리 예정

3.Resource Owner Password Credentials Grant(자원 소유자 자격 증명 방식)

User에게 간단하게 username, password로 Access Token을 받는 방식임

3-1) 특징

• 일반적으로 클라이언트 애플리케이션과 권한 부여 서버가 매우 신뢰되고 동일한 시스템 또는 조직의 일부인 경우에만 권장됨. 클라이언트 애플리케이션이 권한 부여 서버와 리소스 서버를 운영하는 동일한 엔터티에 의해 개발되고 제어되는 자사 애플리케이션의 시나리오의 경우에 사용

• Refresh Token의 사용도 가능함

• 클라이언트가 타사의 외부 프로그램일 경우에는 이 방식을 적용하면 안됨

Q. 타사의 외부 프로그램일 경우에는 안될까?

이 부여 유형은 클라이언트 애플리케이션이 권한 부여 서버를 통해 리소스 소유자(사용자)를 직접 인증하고 리디렉션이나 추가 권한 부여 단계 없이 액세스 토큰을 얻을 수 있는 간단한 방법을 제공한다.

리소스 소유자(사용자)의 자격 증명을 직접 수집해야 하므로 자격 증명 노출 위험이 증가하고, 인증 프로세스의 보안이 손상된다.

그렇기 때문에, 클라이언트 애플리케이션, 권한 부여 서버 및 리소스 서버가 모두 동일한 시스템의 일부인 엄격하게 제어되는 환경에서만 사용되는 것을 권장한다.

3-2) 방식 흐름

★★★★★ ※ 잠깐! 주의 해야 할 전제가 존재한다..! ★★★★★

이 방식의 흐름 전제

• 1.클라이언트 애플리케이션, 인증 서버 및 리소스 서버는 모두 동일한 시스템의 일부라는 가정하여 아래의 단계를 진행해야함
• 2.클라이언트 애플리케이션은 리소스 소유자(사용자)를 대신하여 리소스 서버의 보호된 리소스에 액세스해야함

순서

리소스 소유자 비밀번호 자격 증명 부여 흐름은 다른 OAuth 2.0 흐름에 비해 상대적으로 간단하다. 일반적으로 다음 단계가 진행된다.

1.클라이언트 애플리케이션은 리소스 소유자의 사용자 이름과 비밀번호를 수집한다.

: 간단하게 "클라이언트 애플리케이션에서 자격 증명을 수집한다"라고 말할 수 있다.

2.클라이언트 애플리케이션은 리소스 소유자의 자격 증명과 자체 클라이언트 자격 증명(클라이언트 ID 및 클라이언트 암호)을 포함하여 권한 부여 서버의 토큰 끝점에 요청을 보낸다.

: 클라이언트 애플리케이션은 매개변수를 포함하여 인증 서버의 토큰 엔드포인트에 POST 요청을 보낸다.

*매개변수

• grant_type: 리소스 소유자 비밀번호 자격 증명 부여를 나타내려면 "password"로 설정함
• username: 리소스 소유자가 제공한 사용자 이름임
• password: 리소스 소유자가 제공한 비밀번호
• client_id: 클라이언트 애플리케이션에 할다된 클라이언트 ID
• client_secret: 클라이언트 ID와 연결된 클라이언트 secret, 서버 구성에 따라 선택 사항임

3.인증 서버는 클라이언트 자격 증명과 리소스 소유자 자격 증명의 유효성을 검사한다.
: 인증 서버는 요청을 수신하고 제공된 자격 증명의 유효성을 검사한다.

*자격 증명

• 클라이언트 자격 증명(클라이언트 ID/비밀번호) 확인
• 리소스 소유자의 자격 증명(사용자 이름/비밀번호) 확인

4.자격 증명이 유효하면 인증 서버는 클라이언트 애플리케이션에 액세스 토큰을 발급한다.

• 위에 3번에서 자격 증명이 성공적으로 검증되면 인증 서버는 클라이언트 애플리케이션에 대한 엑세스 토큰을 생성한다.

• 엑세스 토큰 내용은 일반적으로 토큰 유형, 토큰 만료 시간(유효 기간), 범위 등의 정보가 포함되고 있다.

• 인증 서버는 엑세스 토큰이 포함된 HTTP 응답으로 클라이언트 애플리케이션의 요청에 응답한다.

5.그런 다음 클라이언트 애플리케이션은 액세스 토큰을 사용하여 리소스 소유자를 대신하여 리소스 서버의 보호된 리소스에 액세스할 수 있다.

• 클라이언트 애플리케이션은 인증 서버로부터 엑세스 토큰을 받는다.

• 클라이언트 애플리케이션은 보호된 리소스에 엑세스하기 위해 리소스 서버에 대한 후속 요청에 엑세스 토큰을 포함할 수 있다.

• 리소스 서버는 엑세스 토큰의 유효성을 검사하고 토큰이 유효하고 승인된 경우 요청된 리소스에 대한 엑세스 권한을 부여한다.

6.리소스 서버는 보호된 리소스로 응답한다.

• 엑세스 토큰이 유효하고 인증된 경우 리소스 서버는 요청된 보호 리소스로 클라이언트 애플리케이션의 요청에 응답한다.

3-3) 결론

클라이언트 애플리케이션이 권한 부여 서버를 통해 직접 사용자를 인증하고 사용자를 대신하여 보호된 리소스에 엑세스하기 위한 엑세스 토큰을 얻을 수 있도록 하는 방법을 보여준다. 주의할 점은 클라이언트 애플리케이션의 사용자 자격 증명 처리와 관련하여 이 흐름의 보안 영향을 고려해야한다는 것이다.

4.Client Credentials Grant(클라이언트 자격 증명 방식)

클라이언트의 자격증명만으로 Access Token을 획득하는 방식임

3-1) 특징

• OAuth2의 권한 부여 방식 중 가장 간단한 방식으로 클라이언트 자신이 관리하는 리소스 혹은 권한 서버에 해당 클라이언트를 위한 제한된 리소스 접근 권한이 설정되어 있는 경우에 사용된다.

• 이 방식은 자격증명을 안전하게 보관할 수 있는 클라이언트에서만 사용되어야 하며, Refresh Token은 사용할 수 없다.

3-2) 방식 흐름

순서

1.클라이언트 애플리케이션이 엑세스 토큰을 요청한다.

: 클라이언트 애플리케이션은 매개변수를 포함하여 인증 서버의 토큰 엔드포인트에 POST 요청을 보낸다.

*매개변수

• grant_type: 클라이언트 자격 증명 부여를 나타내기 위해 client_credentials로 설정함
• client_id: 클라이언트 애플리케이션에 할당된 클라이언ID
• client_secret: 클라이언트ID와 연결된 클라이언트 비밀번호

2.인증 서버는 클라이언트 자격 증명의 유효성을 검사한다.

• 인증 서버는 요청을 수신하고 제공된 클라이언트의 자격 증명(클라이언 ID/비밀번호)의 유효성을 검사함

3.인증 서버가 엑세스 토큰을 발행한다.

• 클라이언트 자격 증명의 유효성이 성공적으로 확인되면 인증 서버는 클라이언트 애플리케이션에 대한 엑세스 토큰을 생성함

• 엑세스 토큰에는 일반적으로 토큰 유형, 만료 시간, 범위 등의 정보가 포함됨

• 인증 서버는 엑세스 토큰이 포함된 HTTP 응답으로 클라이언트 애플리케이션의 요청에 응답함

4.클라이언트 애플리케이션이 보호된 리소스에 엑세스한다.

• 클라이언트 애플리케이션은 인증 서버로부터 엑세스 토큰을 받음

• 그런 다음, 클라이언트 애플리케이션은 보호된 리소스에 엑세스하기 위해 리소스 서버에 대한 후속 요청에 엑세스 토큰을 포함할 수 있음

• 클라이언트 애플리케이션은 요청 헤더에 엑세스 토큰을 포함하여 리소스 서버의 API에 HTTP 요청을 보냄
  예:) 'Bearer' 토큰과 함께 'Authorization' 헤더 사용

5.리소스 서버가 엑세스 토큰의 유효성을 검사한다.

• 리소스 서버는 클라이언트 애플리케이션으로부터 요청을 수신하고 요청 헤더에서 엑세스 토큰을 추출함

• 리소스 서버는 진위성, 만료 및 범위를 확인하여 엑세스 토큰의 유효성을 검사함

• 엑세스 토큰이 유효하고 승인된 경우 리소스 서버는 요청된 리소스에 대한 엑세스 권한을 부여함

6.리소스 서버는 보호된 리소스에 응답한다.

• 엑세스 토큰이 유효하고 인증된 경우 리소스 서버는 요청된 보호 리소스로 클라이언트 애플리케이션의 요청에 응답함

3-3) 결론

사용자 인증이 포함되지 않으므로, 클라이언트 애플리케이션이 사용자 개입 없이 리소스에 엑세스 해야 하는 경우에 적합하다.

Q.Resource Owner Password Credentials Grant의 방식과 어떤 차이점이 존재하는 걸까?

Resource Owner Password Credentials Grant: 사용자의 자격 증명을 사용하여 해당 사용자의 데이터에 엑세스하기 위해 사용됨

Client Credentials Grant: 클라이언트 애플리케이션이 자신의 데이터나 서비스에 접근하기 위해 사용됨