OAuth에 대해 타인에게 설명할 기회가 있었으므로, 정리해 보았습니다.

인증(Authentication)

인증은 누구인지 확인하는 것입니다.

예를 들어, 암호 인증.
그 사람 밖에 없는 패스워드를 안다면 그것은 본인입니다.

예를 들어, 지문 인증.
생체적 특징이 일치한다면 그것은 본인입니다.

인가(Authorization)

인가란 권한을 주는 것입니다.

인증과 인가는 세트로 되어 있는 경우가 많습니다.
ATM에서 돈을 내려면 캐시 카드와 비밀번호가 필요합니다.
현금카드로 계좌를 확인하고, 비밀번호로 현금카드의 소유자 본인인지를 인증하고, 계좌로부터 돈을 내리는 허가를 부여하고 있습니다.

인증이 없는 허가의 예로는 기차 표가 있습니다.
티켓을 가지고 있으면 기차를 타는 허가가 주어지지만 티켓을 가진 사람은 누군가를 확인하지 않습니다.

API에 대한 권한 부여

예를 들어 클라이언트 앱용 API를 만들었다고 가정합니다.
하지만 API를 무제한으로 게시하면 나쁜 사람이 앱 이외에서 API를 실행합니다. 그래서 앱 안에 비밀 키를 갖게 하고 키가 일치하지 않는 액세스를 연주하기로 합니다. 앱이 허가되었고 나쁜 사람은 허가되지 않은 상태입니다. 다음으로 이 API를 사용하여 사용자별 데이터를 관리하는 것을 고려해 보겠습니다. 이 앱의 사용자에게 모두 동일한 키를 부여한 채로 있으면 다른 사용자의 데이터에서도 업데이트하거나 열람할 수 있습니다. 그래서 같은 앱에서도 사용자마다 다른 키를 부여하기로 하자. 각 사용자는 자신의 데이터에만 업데이트 권한이 부여되었습니다. OAuth OAuth는 위 그림의 허가 메커니즘을 표준화한 것입니다. 권한 부여를 위한 Auth 서버가 등장하여 키 대신 액세스 토큰을 부여합니다. OAuth에는 다양한 방식의 인증 플로우가 있습니다만, 이하는 Implicit 플로우라고 하는 간이한 방식입니다. OAuth에 의한 인증 OAuth는 인가를 위한 구조였습니다만, 그것을 인증에도 사용해 버리자는 생각입니다. Google로 로그인이라든지 Facebook으로 로그인이라든지 자주 있는 것입니다.

OAuth를 인증하는 위험 1

단순한 OAUTH 2.0을 인증에 사용하면, 차가 통과할 수 있을 정도로 목가적인 보안 홀을 할 수 있다

앱 A가 악의적이라면 앱 A가 사용자 A에게 받은 토큰으로 앱 B에 로그인하고,
앱 B 내의 사용자 A의 정보를 열람, 갱신할 수 있습니다.
왜, 이런 일이 일어나는가 하면 OAuth가 인가의 구조이기 때문입니다. 액세스 토큰에는 인증 기능이 없기 때문에 소유자가 누군가 신경 쓰지 않습니다. 앱 B가 OAuth를 로그인에 사용하지 않는 경우, 앱 A는 사용자 A에게 원래 허용된 범위의 정보에만 액세스할 수 있었고 문제는 없었습니다. OpenID Connect OpenID Connect는 OAuth2.0의 작동 방식에 인증 기능을 추가한 것입니다. OpenID Connect는 액세스 토큰과 함께 ID 토큰을 반환합니다. ID 토큰에는 인증에 필요한 다양한 정보가 포함되어 있으며 ID 토큰을 확인하여 OAuth에서 문제가 되었던 취약점을 많이 해결할 수 있습니다. ID 토큰의 검증 예 ＞ Yahoo! ID 연계 ID 토큰 검증
예를 들어, 이전 OAuth의 문제는 다음 검증을 통해 감지할 수 있습니다.

대상 웹사이트 또는 애플리케이션과 다른 서비스에 게시된 ID Token이 아닌지 확인하기 위해 Payload의 aud 값에 대상 웹사이트 또는 애플리케이션에 게시된 Client ID 값이 포함되어 있는지 확인 합니다.

기타

리프레시 토큰이라든가, 클라이언트 시크릿의 문제점등에 대해서도 추기하고 싶다.



그림 : OAuth 2.0에 숨어있는 "5 가지 취약점"과 해결책  ↩