OAuth2.0 State 역할

소개

지난번 은 OAuth2.0 의 인가 코드 그랜트 플로우의 I/F 에 대해 정리했습니다.
그 중에서 갑자기 등장한 State에 포커스하고 정리합니다.

아젠다

인증 코드 그랜트 (복습)

CSRF를 위한 state

OAuth2.0의 CSRF (Cross-Stie-Request-forgery)

state를 사용하여 권한 부여 코드 허용 흐름

요약

허가 코드 그랜트 (복습)

또! 보일 수 있지만 인증 코드 흐름은 흐름이 길다.
어디서 이야기하고 있는지 알기 어렵기 때문에 쓰고 있습니다.
(매번 조금씩 개수하고 있기 때문에 더욱 보기 쉬워지고 있다.

CSRF 대책을 위한 State

RFC6749 의 state 의 설명에 확실히 CSRF 대책을 위해서 도입해야 한다, 라고 기재되어 있습니다.

The parameter SHOULD be used for preventing cross-site request forgery
訳) このパラメータはcross-site request forgery(CSRF)対策のために使用すべき

이것만 읽고, 아, 과연 CSRF 때문에? . .
그렇지는 않습니다.
적어도 나는 되지 않았다.

따라서 OAuth2.0의 CSRF는 무엇입니까?

OAuth2.0의 CSRF (Cross-Stie-Request-forgery)

OAuth2.0의 CSRF는 소위 일반적인 CSRF와 약간 의미가 있습니다.
OAuth2.0의 CSRF 공격은 공격의 대상이 되는 사용자에게 공격자의 리소스를 처리할 수 있는 권한을 부여하는 것입니다.

실제 흐름은 다음과 같습니다.

공격자가 권한 흐름을 시작하고 권한 화면에서 권한을 부여합니다

일반적으로 허가 후 응답에서 리디렉션을 어떠한 방식으로 리디렉션하지 않고 중지합니다.

원래 리디렉션을 수행하는 값 (RedirectURI + 권한 부여 코드)을 공격 대상에게 보냅니다.

공격자의 리소스를 처리 할 수있는 정보가있는 토큰이 공격 대상에게 연결됩니다.

이러한 상황하라면 다음과 같은 일이 일어납니다.
공격자는 Qiita에 게시물을 타사 앱에서 게시한다고 가정합니다.
그러나 게시물은 공격 대상자 자신의 계정이 아니라 공격자의 계정에 게시됩니다.

state를 사용한 권한 부여 권한 부여 흐름

위와 같은 문제가 발생하는 이유는, 인가한 유저와 인가 후의 리디렉션을 실시한 유저가 함께 있는 것이 담보되어 있지 않은 것입니다.
따라서 허가 화면의 전후에 행해지고 있는 처리가 같은 사람이라는 것을 담보하기 위한 값이 State 입니다.
State 를 사용하면 아래 그림과 같습니다.

권한 부여 요청시 세션에 연결하는 State를 발행하고 State도 함께 보냅니다.

인증 서버는 전송 된 값을 그대로 반환합니다.

인증 코드가 리디렉션 될 때 상태를 확인하고 실수로 리소스를 처리하지 않습니다.

라는 흐름이 되어 CSRF 공격을 막고 있습니다.

요약

이번에는 OAuth2.0과 CSRF 대책에 대해 정리했습니다.
State를 사용하여 cross-site request forgery(CSRF)를 방지합니다.
하지만 이 방법을 사용하면 권한 공급자가 클라이언트가 올바르게 상태를 사용할 수 있는지 확인할 수 없습니다.
따라서 오늘은 state 대신 PKCE를 사용하여 CSRF 대책을 수행하는 것 같습니다.
다음 번은 PKCE 주위에 대해 정리할 예정입니다.