Open Authorization Framework 2.0?

Oauth를 사용하는 이유?

사용자의 권한을 인증, 인가하기 위하여 ID와 비밀번호의 직접적인 전달을 하는 것은 탈취될 가능성이 존재한다. 이를 방지하고 안전하게 필요한 정보를 넘겨받기 위해 사용하게 된다.

 

Oauth는 권한 위임을 위해 사용되는 프로토콜이며, 직접적으로 인가를 수행하기보단 요청할 수 있는 흐름과 수단을 제공한다.

 

웹 또는 모바일에서 개인 정보에 대한 액세스 권한을 요청받은 경우 해당 프로토콜을 사용하였을 것이다.

 

 

 

Oauth의 장점

• HTTP / HTTPS를 이용해 동작하는 프로토콜이기에 범용적으로 사용할 수 있다. 
• 단순하게 구현할 수 있고, 많은 양의 레퍼런스를 가진다.
• 스펙이 강제하는 부분이 적고, 선택적으로 제공하거나 자유함으로 필요에 맞게 변경할 수 있는 부분이 많다.

 

 

Oauth의 단점

• Oauth 스펙은 대부분의 요소 포맷 등이 명확히 정의되어있지 않고 확장 가능하기 때문에, 설계의 유연함을 가지지만 반대로 여러 Oauth 서비스가 크게 다른 구현부, 확장 점을 가짐으로써 각 서비스가 호환이 되지 않을 수 있다.
• 스펙상 토큰의 수명 주기와 범위가 지정되어 있지 않기에 토큰이 만료되지 않을 수도 있다. 구현을 통해 해결할 수 있다.
• 서비스에 필요한 사용자 정보를 가져오기 위해 추가적인 요청이 있을 수 있다. JWT로 대체 가능하다. 
• 스펙상 SSL과 TLS를 권장하나, 강제하지 않고 설정하지 않는한 일반적인 HTTP 프로토콜을 사용하기에 통신 도청과 토큰 탈취 등이 쉽게 일어날 수 있다.

 

 

Oauth의 취약점

CSRF

Access Token 생성시 state 매개변수를 이용함으로써 방지할 수 있다. 

 

해당 변수 검증 누락이나 미흡시 토큰을 탈취당할 수 있다. 

 

 

Convert Redirect 

redirect_uri 파라미터에 대한 검증 누락이나 미흡시 발생하는 취약점이다. 

 

변조된 URI를 통해 공격받을 수 있다.

 

Full Path 검증 등 강력한 방법을 사용하여야 한다.

 

 

 

Oauth의 구성 주체

Resource Owner (User, Device)

Resource Server에서 제공하는 기능을 이용하려고 하는 주체이며, 클라이언트에게 API 접근 권한을 위임할 수 있다. 이는 인증 정보 전달과 권한 위임 절차 수행을 통해 이루어진다.

 

별도의 소프트웨어 구성 요소가 아니라 서비스(리소스 서버의) 사용자를 의미한다.

 

ID와 password등을 이용해 Resource Client에 접근 권한을 인가한다. (액세스 토큰)

 

 

Resource Client (Somaeja)

리소스의 소유자를 대신하여 인가 서버를 통해 발급된 액세스 토큰을 가지고 Resource Server의 API와 상호작용을 하는 주체이다.

 

Resource Owner로부터 권한 인가를 받아 액세스 토큰을 획득하고 API 서버에게 요청한다.

 

 

Resource Server (Google, Facebook)

보호된 Resource를 관리하며 Client에게 Resource와 관련된 API를 제공한다.

 

전달받은 액세스 토큰이 유효한지 확인하기 위해 매번 Authorization Server와 통신한다.

 

이러한 방식은 비효율적인 구조를 가지기에 인가 내역을 캐싱하거나 JWT등을 이용한다.

 

 

Authorization Server (Facebook-auth Server, Google-auth Server)

인가 서버는 리소스 소유자와 클라이언트의 정보를 인증하고, 권한을 위임할 수 있는 메커니즘을 제공한다.

 

Resource Server가 올바른 액세스 토큰을 받았는지 검증 요청하는 것을 처리하고, 만료된 액세스 토큰을 폐기하기도 한다. 추가적으로 Resource Client의 요청을 제어하기 위해 해당 권한들을 제어할 수 있는 Client ID와 Secret 정보를 관리한다.

 

 

 

Oauth의 구성 요소

Access tokens

클라이언트에게 권한이 위임되었다는 것을 나타내기 위해 인가 서버가 클라이언트에게 발급해주는 요청 정보이다.

 

사용자가 제공한 인증 정보를 통해 만들어진 인가 코드와, 클라이언트의 자격 증명 정보, 검증 정보, 토큰의 접근 권한 등급 등의 정보들을 통해 만들어진다.

 

 

Oauth accessToken 발급을 위한 정보, 요소들의 역할 (제네럴하게..?)

https://authorization-server.com/auth
 ?response_type=code
 &client_id=1
 &redirect_uri=https://example.com/callback
 &scope=A+B+C
 &state=asdaea23ffas214loxzcfh

STATE : CSRF를 방어하기 위해 사용하는 매개변수이다.

 

CLIENT_ID : Oauth API 관련 자격 증명 페이지에서 사용 승인을 통해 설정되는 식별 값이다.

 

CLIENT_SECRET : 클라이언트를 인증하는 수단으로 사용되는 값으로 해당 값을 클라이언트가 전달하고 인증 서버는 이 값을 확인함으로써 요청할 권한이 있는 클라이언트인지 확인한다.

 

이를 통해 승인되지 않은 악성 앱이 유효한 액세스 토큰을 얻지 못하게 한다.

 

SCOPE : 응용 프로그램이 요청하는 권한을 나타내는 문자열이다. Oauth API가 지원하는 범위를 정의한다.

 

REDIRECT_URI : 사용자가 요청을 승인한 후 리디렉트 할 위치를 인증 서버에 제공한다.

 

 

Refresh tokens

액세스 토큰과 달리 보호된 리소스들에 접근할 때 사용되지 않으며, 기존에 발급된 액세스 토큰을 재발급할 때 사용하는 토큰이다.

 

액세스 토큰의 만료로 리소스 서버의 접근할 수 없을 때, 리프래시 토큰을 인가 서버에 전달함으로써 새로운 액세스 토큰과 리프레시 토큰을 제공받을 수 있다.

 

 

 

Oauth Flow ( Authorization code grant )

1. 클라이언트(Somaeja)는 소유자를 인가 서버의 인가 포인트로 리다이렉트 시킨다.
2. 소유자는 인가 포인트에서 사용자 정보를 이용해 소유자 인증을 수행한다. id, password
3. 인가 서버는 client id와 redirect_url 정보를 등록된 것과 비교한다. 틀린 경우 요청 취소
4. 인가 서버가 클라이언트에 대해 권한을 인가할지 질의하고 소유자는 권한을 위임한다.
5. 인가 서버가 해당 클라이언트의 포인트로 요청을 리다이렉트 하고, 인가 코드를 전달한다.
6. 클라이언트의 요청 포인트에 인가 코드 정보가 전달된다.
7. 클라이언트는 받은 인가 코드와 기존에 설정된 자격 증명 정보를 담아 토큰 생성과 관련된 인가 서버의 포인트에 요청을 전송한다.
8. 인가 서버는 해당 정보를 검증하고 클라이언트에게 액세스 토큰을 생성하여 전달한다.
9. 클라이언트는 액세스 토큰을 이용하여 API 서버 혹은 포인트에 요청을 전송한다.
10. 해당 API 서버, 포인트는 요청을 확인하고 리소스를 제공한다.