OAuth 2.0 이란?
- 인증을 위한 업계 표준 프로토콜이며, 애플리케이션에서의 특정 권한 부여 흐름을 제공하는 동시에 개발자의 단순성에 초점을 맞춥니다.
- 써드파티 프로그램에게 리소스 소유자를 대신하여 리소스 서버에서 제공하는 자원에 대한 접근 권한을 위임하는 방식을 제공합니다.
이전에는 어쨌길래?
이전에는 A에서 B의 리소스를 가져오기 위해서는 B의 ID, Password 를 직접 입력하여 필요할 때 마다 불러와서 요청하는 방식을 사용했습니다. 이런 방식에서의 문제점은 다음과 같습니다.
- 사용자 입장에서는 A에게 B에 있는 내 개인 정보를 넘기기엔 신뢰도가 부족합니다.
- A 입장에서는 B의 ID, Password 를 모두 받았기 때문에 신뢰도가 높아야하는 부담이 생깁니다.
- B 입장에서는 A를 그냥 신뢰할 수 없으니 함부로 리소스를 제공하면 안됩니다.
이러한 문제점을 해결하고자 나온 것이 OAuth 인증 방식입니다.
주요 용어
| 용어 | 설명 |
|---|---|
| Resource Server | 사용자의 보호된 자원을 호스팅하는 서버, 다시 말해 OAuth 서비스를 제공하며 자원을 관리하는 서버입니다. |
| Resource Owner | Resource Server 의 계정을 보유하고 있는 사용자입니다. OAuth 프로토콜 흐름에서 클라이언트를 인증하는 역할을 수행합니다. 어떻게 보면 중재자 역할을 한다고 생각해도 될 것 같네요. |
| Client | 보호된 자원을 사용하려고 접근 요청을 하는 애플리케이션입니다. |
| Authorization Server | Client 가 Resource Server 의 서비스를 사용할 수 있게 인증하고 토큰을 발행해주는 서버입니다. |
| Access Token | 리소스 서버에게서 리소스 소유자의 보호된 자원을 획득하려할 때 사용되는 만료 기간이 있는 Token 입니다. (대체로 만료 기간이 짧습니다.) |
| Refresh Token | Access Token 이 만료되었을 때 이를 갱신하기 위해 사용하는 Token 입니다. 일반적으로 Access Token 보다 만료 기간이 깁니다. |
| Authentication | 인증 → 접근 자격이 있는지에 대해 검증한다는 뜻입니다. |
| Authorization | 인가 → 리소스에 접근할 수 있는 권한을 부여한다는 뜻입니다. 이 단계가 완료되어야 권한이 담긴 Access Token 을 Client 에게 부여할 수 있습니다. |
Request & Response
위에서 주요 용어들에 대해서 다루었다면 이번에는 주요 API parameter 들에 대해서 한 번 알아보고 넘어가도록 하겠습니다.
| parameter | 설명 |
|---|---|
| client_id, client_secret | 클라이언트의 자격증명입니다. Authorization Server 에서 클라이언트의 검증에 사용합니다. |
| redirect_url | Authorization Server 에서 Client 가 요청한 응답을 보낼 때 사용할 url 입니다. |
| response_type | 권한 부여 방식에 대한 parameter 이며 아래 값 중 하나를 사용합니다. - code: Authorization Code Grant - token: Implicit Grant |
| state | CSRF 공격에 대비하기 위해 클라이언트가 권한서버에 요청 시 포함하는 임의의 문자열입니다. 필수 사항은 아니지만 클라이언트가 요청 시에 state 를 포함시켰다면, Authorization Server 는 똑같이 클라이언트에게 보내야 합니다. |
| grant_type | Access Token 요청 시 포함되는 값으로, 권한 부여 방식에 대한 설정입니다. 아래 값 중 하나를 사용합니다. - authorization_code: Authorization Code Grant - password: Resource Owner Password Credentials Grant - client_credentials: Client Credentials Grant |
| code | Authorization Code Grant 방식에서 Access Token 요청 시에 사용됩니다. Authorization Server 에서 받은 code 와 동일합니다. |
| token_type | 발행된 Token 의 타입으로, 대표적으로 Baerer, MAC(Message Authentication Code) 가 있습니다. |
| expires_in | 토큰의 만료 시간입니다. |
❔ CSRF 공격이란? → 사이트 간 요청 위조
사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위를 특정 웹사이트에 요청하게 하는 공격입니다.
여러가지 인증 절차
OAuth 2.0 프로토콜에서는 권한 부여 방식에 따른 4가지 종류로 구분하여 제공하고 있습니다.
1. Authorization Code Grant (권한 부여 승인 코드 방식)
- 권한 부여 승인을 위해 자체 생성한 Authorization Code 를 전달하는 방식으로 많이 쓰입니다.
- 보통 타사의 클라이언트에게 보호된 자원을 제공하기 위한 인증에 사용됩니다.
- Refresh Token 의 사용이 가능합니다.
- Access Token 이 Authorization Server 와 Client, Resource Server 를 옮겨다닐 때 공격자가 중간에 가로챌 위험이 있습니다.
2. Implicit Grant (암묵적 승인 방식)
- 자격증명을 안전하게 저장하기 힘든 클라이언트에게 최적화된 방식입니다.
- 앞서 소개한 권한 부여 승인 코드 없이 바로 Access Token 이 발급됩니다.
- Refresh Token 사용이 불가능합니다.
- Access Token 이 URL을 통해 전달되므로 위험합니다.
- 그래서 Access Token 의 만료 기간을 되도록 짧게 설정하여 위험을 줄여야 합니다.
3. Resource Owner Password Credentials Grant (자원 소유자 자격증명 승인 방식)
- OAuth 제공자가 서비스하는 애플리케이션에서만 사용가능한 방식입니다.
- 단순히 username 과 password 로 자격을 증명하는 방식입니다.
- 물론 Refresh Token 은 사용할 수 있습니다.
4. Client Credentials Grant (클라이언트 자격증명 승인 방식)
- 가장 간단한 방식으로, 클라이언트 자신이 관리하는 리소스 혹은 권한 서버에 해당 클라이언트를 위한 제한된 리소스 접근 권한이 설정되어 있는 경우 사용됩니다.
- 한마디로 그냥 클라이언트 자체가 Resource Owner 인 경우를 뜻한다고 생각하면 좋을 것 같습니다.
- Refresh Token 을 사용할 수 없습니다.
참고
🌱 주니어 안드로이드 개발자 최우영입니다.