OAuth(OpenID Authentication) 란?
OAuth는 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준이다. 이 매커니즘은 여러 기업들에 의해 사용되는데, 이를테면 아마존, 구글, 페이스북, 마이크로소프트, 트위터가 있으며 사용자들이 타사 애플리케이션이나 웹사이트의 계정에 관한 정보를 공유할 수 있게 허용한다.
- 위키백과 발췌
인터넷을 하다 보면 흔히 위와 같은 로그인 창을 본적이 있을 것이다. 별도의 회원가입 없이 해당 플랫폼의 계정만 있으면 편리하게 서비스를 이용 할 수 있게 해주는 기능이다.
토큰 기반의 인증 방식에서 Token의 발급과 인증에 대한 작업을 다른 외부 플랫폼에서 처리하는 방식으로 볼 수 있다.
OAuth 1.0 과 2.0
OAuth 1.0은 구현이 복잡하고 AccessToken이 만료 되지 않으며 HMAC을 통해 암호화를 하는 등 번거로운 과정이 필요 하다면 2.0의 경우 기능이 단순화 되었으며 Https 통신을 통해 암호화를 처리하며 인증 방식또한 다양해졌다.
OAuth Abstract Protocol Flow
Resource owner : 사용자
Client: Resource Server 에서 제공하는 자원을 사용하는 애플리케이션 (Application)
Resource server : 자원을 호스팅하는 서버 (API server)
Authorization Server: 사용자의 동의를 받아서 권한을 부여하는 서버
인증의 종류
OAuth Grant Types
Authorization Code Grant Flow
가장 일반적인 유형으로 웹 및 모바일 앱에서 사용된다. Application은 인증 코드를 통해 인증 서버에서 Access Token을 교환하는 방식이다.
1. Access Application : 사용자가 앱 혹은 웹에 액세스하여 인증 및 권한 부여를 요청한다.
2. Authentication and Request Authorization : Application(이하 앱)은 사용자를 인증 서버로 리디렉션하여 사용자에게 사용자 이름과 비밀번호를 묻는다. 사용자가 앱에 대해이 흐름을 처음으로 거치면 사용자에게 승인 페이지가 표시되며 이 페이지에서 사용자는 자신을 대신하여 리소스에 액세스 할 수 있도록 앱에 권한을 부여하는 권한을 선택할 수 있다.
3. Authentication and Grant Authorization : 인증 서버는 인증 및 권한 부여를 받는다.
4. Send Authorization Code : 사용자가 앱을 인증하면 인증 서버가 리다이렉트를 통해 인증 코드를 앱에 전송한다.
5. Request Code Exchange for Token : 앱은 인증 코드를 사용하여 인증 서버에 Access Token을 요청한다.
6. Issue Access Token : 인증 서버가 인증 코드를 검증하고 Access Token을 발급한다.
7. Request Resource with Access Token : 앱이 Access Token을 제시하여 리소스 서버의 리소스를 요청한다.
8. Return Resource : Access Token이 유효하다면 해당 리소스를 반환/처리한다.
Client Credentials Flow
자체적으로 Access Token을 요청하고 리소스에 접근 할 수 있는 방식으로 사용자 없이 API를 호출 하는 방식에 사용한다.
1. Authenticate with Client ID and Secret : 앱이 Client ID 와 Client Secret으로 인증 서버에 인증을 요청한다.
2. Issue Access Token : 인증 서버는 Client ID와 Client Secret을 확인하고 Access Token을 발급한다.
3. Request Resource with Access Token : 앱이 Access Token을 제시하여 리소스 서버의 리소스를 요청한다.
4. Return Resource : Access Token이 유효하다면 해당 리소스를 반환/처리한다.
Resource Owner Password Grant Type (Legacy)
리소스 소유자가 자격 증명을 앱과 직접 공유 하는 매우 신뢰할 수 있는 앱용이다.
1. Authenticate with Username and Password :사용자 이름과 암호를 사용하여 앱 사용자를 인증한다.
2. Send Username/Password : 앱이 유효성 검사를 위해 사용자 이름과 비밀번호를 인증 서버로 보낸다.
3. Issue Access Token :인증 서버가 사용자 이름과 비밀번호를 확인하고 액세스 토큰을 발급한다.
4. Request Resource with Access Token : 앱이 Access Token을 제시하여 리소스 서버의 리소스를 요청한다.
5. Return Resource : Access Token이 유효하다면 해당 리소스를 반환/처리한다.
Implicit Grant Type (Legacy)
중간 코드 교환 단계 없이 엑세스 토큰을 가지고 오는 방식으로 Client 암호의 기밀이 보장되지 않는 앱에서 사용된다.
* 암호를 안전하게 저장할 방법이 없는 특정 상황에서만 권장되는 방식
1. Access Application : 사용자가 앱 혹은 웹에 액세스하여 인증 및 권한 부여를 요청한다.
2. Authentication and Request Authorization : 앱은 사용자의 계정정보를 입력 하라는 메세지를 표시한다. 사용자는 자신을 대신하여 리소스에 엑세스 할 수 있도록 앱에 권한을 부여할수 있다.
3. Authentication and Grant Authorization : 권한 서버는 인증 및 권한을 부여 받는다.
4. Issue Access Token :인증 서버가 인증 코드의 유효성을 검사하고 리디렉션 URL과 함께 액세스 토큰을 반환한다.
5. Request Resource with Access Token in URL : 앱이 URL에 액세스 토큰을 제공하여 리소스 서버에서 리소스를 요청한다.
6. Return Resource : Access Token이 유효하다면 해당 리소스를 반환/처리한다.
이미지 출처 : https://docs.pivotal.io/p-identity/1-11/grant-types.html
추가 수정 사항
OAuth Grant Types에 PKCE, Device Code, Refresh Code가 추가 되었다.
PKCE (Proof Key for Code Exchange) Flow
여러 공격을 방지하고 공용 클리이언트에서 OAuth 교환을 안전하게 수행 할 수 있는 Authorization Code Flow의 확장형이다.
원래 모바일 앱을 보호하도록 설계 되었지만 인증 코드 삽입을 방지하는 기능으로 인해 모든 OAuth Cleint, 심지어 Client Secret을 사용하는 웹앱에서도 유용하다.
1. Authorization Request + t(code_verifier), t_m : 앱은 'code_verifier'라는 이름의 secret을 생성 및 저장하고 변환 방법 't_m'으로 변환 된 't(code_verifier)'를 t_m과 함께 인증서버에 요청한다. ('t(code_verifier)'를 'code_challenge'라 한다)
2. Authorization Code : 평소와 같이 응답 하지만 't(code_verifier)' 및 't_m'을 저장한다.
3. Access Token Request + code_verifier : (1)에서 생성된 'code_verifier'를 담아 Access Token을 요청한다.
4. Access Token : 권한 서버는 'code_verifier'를 저장된 't_m' 방법으로 변환하여 't(code_verifier)'와 비교 한 후 같이 않으면 엑세스를 거부한다.
(2)에서 인증 토큰을 가로채더라도 'code_verifier'를 몰라 Access Token으로 교환 할 수 없다.
Device Code Grant Flow
입력이 없거나 제한된 장치에서 사용되는 기능으로 인증을 시도 할 때 해당 장치에서는 Device Code와 User Code 및 접근 가능한 URI 생성하고 해당 Device Code를 입력이 자유로운 핸드폰이나 PC환경에서 해당 URL에 Device Code 및 User Code 를 입력하여 인증 받는 방식이다. 흔히 Smart TV에서의 YouTube 로그인을 예로 들 수 있다.
1. Client Identifier : Device Client이하 클라이언트 는 권한 서버에 엑세스를 요청하고 요청에 Client Identifier (클리이언트 식별자)를 포함한다.
2. Device Code, User Code & Verification URI : 인증 서버는 Device Code와 End User Code를 발급하고 최종 사용자 확인 URI를 제공한다.
3. User Code & Verification URL : 클라이언트는 End User에게 다른 장치에서 사용자 에이전트를 사용하고 제공된 확인 URI를 방문하여 인증 받도록 지시한다. 클라이언트는 인증을 위한 End User Code를 사용자에게 제공한다.
4. End User Reviews Authorization Request : 인증 서버는 사용자 에이전트를 통해 최종 사용자를 인증하고 사용자에게 클라이언트에서 제공한 End User Code를 입력한다. 권산 서버는 사용자가 입력한 End User Code의 유효성을 검사하고 인증을 확인 받는다.
5. Device Code & Client Identifier : 최종 사용자가 클라이언트의 요청을 검토 하는 동안 클라이언트는 사용자가 권한 부여 단계를 완료 했는지 확인 하기 위해 권한 서버를 반복적으로 Polling 한다. 이때 클라이언트는 Device Code 와 Client Identifier를 포함한다.
6. Access Token : 인증 서버는 클라이언트가 제공한 Device Code 의 유효성을 검사하고 클라이언트에 액세스 권한 이 부여 된 경우 Access Token을 돌려준다.
Refresh Token Grant
클라이언트의 Access Token이 만료되었을 때 Refresh Token을 사용하여 Access Token을 교환하는 방식이다.
이를 통해 클라이언트는 사용자와 더 이상 상호 작용하지 않고도 유효한 Access Token을 계속 가질 수 있다.
1. Authorization Grant : 클라이언트는 인증 서버로 인증 하여 Access Token을 요청하고 권한 부여를 제시 한다.
2. Access Token & Refresh Token : 인증 서버는 클라이언트를 인증을 확인 하고 유효할 경우 권한을 부여하여 Access Token 과 Refresh Token을 발급한다.
3. Access Token : 클라이언트가 Access Token을 이용하여 리소스 서버에 Protected Resource를 요청한다.
4. Protected Resource : Access Token이 유효 할 경우 해당 리소스를 반환/처리한다.
5. Access Token : Access Token이 만료 될 때까지 (3)~(4)을 반복한다.
6. Invalid Token Error : 만료된 Access Token으로 요청이 왔을 경우 유효하지 않은 토큰 임을 알려준다.
7. Refresh Token : Access Token이 만료 되었음을 확인 할 경우 클라이언트는 (2)에서 발급 받은 Refresh Token으로 인증 서버에 새로운 Access Token을 요청한다.
8. Access Token & Optional Refresh Token : 인증 서버는 클라이언트를 인증하고 Refrest Token이 유효한 경우 새 Access Token (및 Refresh Token)을 발급한다.
참조
- https://oauth.net/2/
