OAuth 2란 무엇인가?

1. OAuth 2 프레임워크

OAuth (Open Authorization)는 인터넷 서비스와 애플리케이션 사이의 안전하고 제한된 접근을 가능하게 해주는 인증 및 권한 부여 프레임워크입니다.

OAuth는 사용자가 자신의 정보를 제3자 애플리케이션과 공유할 수 있도록 도와주며, 사용자의 암호를 제3자와 공유하지 않아도 된다는 점에서 보안적으로 유리한 방식입니다.

타사 웹 사이트나 웹이 리소스에 접근할 수 있게 허용하는 것이 주 목적이다.

OAuth 2는 특정 구현이나 라이브러리가 아니라는 점이 중요하다.

 

OAuth 2는 그랜트(Grant)라고 하는 토큰을 얻는 여러 방법을 제공한다.

• 승인 코드 (Authorization Code 그랜트)
• 암호 (Resource Owner Password Credentials 그랜트)
• 클라이언트 자격 증명 (Client Credentials 그랜트)
• 갱신 토큰 (Refresh Token 그랜트)

2. 승인 코드 그랜트 유형

이 유형은 가장 많이 이용되는 OAuth 2 흐름 중 하나이다.

2.1. 인증 요청

클라이언트는 사용자가 인증해야 하는 권한 부여 서버의 엔드포인트로 사용자를 리디렉션한다.

A 앱에서 리소스에 접근해야 한다고 가정했을 때, 앱 A는 리소스에 접근하기 위해 인증해야 하므로 사용자가 자격 증명을 입력할 수 있는 권한 부여 서버의 로그인 양식이 있는 페이지를 연다.

(*사용자가 권한 부여 서버와 직접 상호 작용하며 클라이언트 앱으로 자격 증명을 보내는 것이 아님)

기술적으로 사용자를 권한 부여 서버로 리디렉션할 때 클라이언트는 다음 세부 정보가 포함된 요청 쿼리로 권한 부여 엔드포인트를 호출한다.

• response_type
  • 클라이언트가 코드를 기대한다는 것을 알리는 값
• client_id
  • 애플리케이션을 식별하는 ID
• redirect_uri
  • 인증 성공 후 사용자를 리디렉션할 위치를 권한 부여 서버에게 알림
• scope
  • 허가된 권한
• state
  • CSRF 보호를 위한 토큰 정의

인증에 성공하면 권한 부여 서버는 리디렉션 URI로 클라이언트를 다시 호출하고 코드와 상태 값을 제공한다.

2.2. 액세스 토큰 얻기

1단계에서 생성된 코드는 사용자가 리소스에 접근할 수 있도록 사용자가 인증했다는 클라이언트의 증명이다.

그래서 이것을 '승인 코드 그랜트 유형'이라고 부른다.

이제 클라이언트는 토큰을 얻기 위해 코드로 권한 부여 서버를 호출한다.

(1단계에서는 사용자와 권한 부여 서버 간에 상호 작용이 수행됐다. 2단계에서는 클라이언트와 권한 부여 서버의 상호 작용이 수행된다.)

클라이언트는 액세스 토큰을 얻기 위해 다음 사항을 제시하고 호출한다.

• 사용자의 허가를 입증하는 승인 코드
• 자신이 승인 코드를 가로챈 다른 사람이 아니며 실제로 같은 클라이언트임을 증명하는 자격 증명

아래의 정보를 포함하여 클라이언트는 권한 부여 서버에 요청한다.

• code
  • 1단계에서 받은 승인 코드. 기서은 사용자가 인증 받았음을 증명
• client_id 및 client_secret
  • 클라이언트의 자격 증명
• redirect_uri
  • 1단계에서 검증에 사용된 것과 같음
• grant_type
  • authotization_code 값을 가진다. 현재 실행된 인증 방법을 지정한다.

서버는 이것에 대한 응답으로 access_token을 반환한다.

이 토큰은 클라이언트가 리소스 서버에서 노출하는 리소스를 호출하는 데 사용할 수 있는 값이다.

2.3. 리소스 호출

권한 부여 서버에서 액세스 토큰을 받고 나면 이제 클라이언트는 보호된 리소스를 호출할 수 있다.

클라이언트는 리소스 서버의 엔드포인트를 호출할 때 권한 보여 요청 헤더의 액세스 토큰을 사용한다.

2.3.1. 전체 흐름의 비유

1. 사용자) 야, 깃허브 리소스 서버 가서 내 정보 좀 가져와
2. 웹 서비스 A) 나 깃허브 리소스 서버 못가..
3. 사용자는 깃허브 권한 서버에 연락한다.
   1. 사용자) 어, 난데 A 서비스가 접근하려고 하면 허용해줘
   2. 깃허브) 너 누군데?
   3. 사용자) username / password
   4. 깃허브) 아, username 이구나 알겠어.
4. 깃허브 권한 서버는 웹 서비스에게 연락한다.
   1. 깃허브) 사용자한테 이야기 들었어. 리소스 서버에 접근하길 원한다면 이 code를 보여줘. 이건 사용자가 깃허브에 로그인했다는 인증이야.
5. 웹 서비스는 리소스 서버에 접근하기 위해 권한 서버에게 code를 보낸다.
6. 권한 서버는 code를 확인하고(사용자가 웹 서비스에게 리소스 서버에 접근하도록 허락한 것을 확인) 토큰을 건넨다.
7. 웹 서비스는 토큰을 사용하여 인증하고 깃허브 리소스 서버에 있는 사용자의 정보를 가져온다.

3. 암호 그랜트 유형

리소스 소유자 자격 증명 그랜트 유형이라고도 한다.

클라이언트가 사용자 자격 증명을 수집하고 이를 이용해 인증하며 권한 부여 서버에서 액세스 토큰을 얻는다.

이 인증 흐름은 클라이언트와 권한 부여 서버를 같은 조직에서 구축하고 유지 관리할 때만 이용한다.

굳이 같은 조직의 애플리케이션으로 리디렉션될 필요가 없기 때문이다.

암호 그랜트 유형을 이용하면 애플리케이션이 사용자에게 로그인 양식을 보여주고 클라이언트가 서버에 자격 증명을 보내 인증 과정을 처리한다.

3.1. 액세스 토큰을 요청

클라이언트가 사용자 자격 증명을 수집하고 권한 부여 서버를 호출해 액세스 토큰을 얻는다.

3.2. 액세스 토큰으로 리소스 호출

액세스 토큰으로 리소스에 접근할 수 있다.

4. 클라이언트 자격 증명 그랜트 유형

이 방식은 OAuth 2가 지원하는 가장 단순한 그랜트 유형이며 사용자가 관여하지 않을 때, 즉 두 애플리케이션 간의 인증을 구현할 때 이용한다.

처리 과정은 암호 그랜트 유형과 비슷하지만 유일한 차이는 액세스 토큰을 요청할 때 사용자 자격 증명이 필요하지 않다는 것이다.

클라이언트가 사용자의 리소스가 아닌 리소스 서버의 엔드포인트를 호출해야 할 때 이 그랜트 유형을 선택한다.

4.1. 액세스 토큰을 요청

클라이언트는 권한 부여 서버에 요청을 보낸다.

요청에 대한 응답으로 액세스 코드를 받는다.

4.2. 액세스 토큰을 이용해 리소스 호출

액세스 코드로 리소스에 접근한다.

5. 갱신(Refresh) 토큰으로 새 액세스 토큰 얻기

 

만료되지 않는 액세스 토큰은 사용자 자격 증명 노출만큼 위험하다.

이런 위험을 방지하기 위해 토큰의 수명을 짧게 만들어야 한다.

토큰이 만료되면 새로운 토큰을 얻어야 한다.

만약 갱신 토큰으로 새 액세스 토큰을 발급받지 않는다면 액세스 토큰이 만료될 때마다 사용자는 다시 인증해야 한다.