イチカラOAuthとOIDC理解#2 - OAuthとOIDCの違い
概略
OAuth2.0とOpenID Connect(OIDC)の違いの説明。
OAuth2.0は認可のプロトコルでOIDCはOAuth2.0をユーザー認証として活用できるように拡張されたもの。
この記事で説明しないこと
OAuth 2.0のフローごとの説明。
OAuth2.0とは
認可のプロトコルであり、リソースオーナーがクライアントアプリケーションが自身のリソースへのアクセスを認可することで、クライアントアプリケーションはリソースにアクセスができるようするための手段。
クライアントアプリケーションがリソースにアクセスする認可を得る手段として、複数の方式が定義されている。
ユースケースに応じて、どのフローを利用するかを選定する。
方式
・認可コードフロー(Authorization Code Grant type)
・インプリシットフロー(Implicit Grant type)
・リソースオーナー・パスワード・クレデンシャルズフロー(Resource Owner Password Credentials Grant type)
・クライアント・クレデンシャルズフロー(Client Credentials Grant type)
・アサーションフロー(Assersion Grant type)
イメージ図
OIDCとは
OAuth2.0は認可のプロトコルであり、認証のプロトコルではない。
しかし、OAuth2.0にはいつログインしたかなどの認証時の情報やemailなどのユーザーの情報を取得する方法が規定されておらず、リソースサーバー側が独自に実装して提供しないといけなかった。
このため、一つの標準規約としてOAuth2.0を拡張したOpenID Connectが登場した。
OAuth2.0とOIDCの違い
| OAuth2.0/OIDC | クライアントアプリケーションの呼び方 | クライアントアプリケーションを操作するユーザーの呼び方 | アクセストークンを発行するサーバー | UserInfo エンドポイントあるか | IDトークンは発行されるか |
|---|---|---|---|---|---|
| OAuth2.0 | Client | リソースオーナー | 認可サーバー(Authorization Server) | 無い | 発行されない |
| OIDC | Relying Party (RP) | エンドユーザー | IdP(OpenID Provider) | 有る | 発行される |
※IDトークンにユーザーの情報が含まれる場合もあるので、実際はUserInfoエンドポイントが無くても成り立つ場合がある。
IDトークンとアクセストークンの用途の違い
| IDトークン/ アクセストークン |
説明 |
|---|---|
| アクセストークン | クライアントアプリケーションに対して発行されたリソースサーバーにアクセスをしても良いと示すもの。 |
| IDトークン | ユーザーが認証されたこと証明するトークン。認証した日時やusernameやemailなどのユーザー情報が入っている |
※アクセストークンでリソースサーバーが提供するAPIへのアクセスする。
IDトークンでリソースサーバーにアクセスするのはNG.
ちまたで言われているOAuth認証はするな。OIDCを使え！
といわれているが、でもTwitterやFacebookで認証できるサービス実際にある。
TwitterやFacebookは独自にフローを拡張して認証を提供しているらしい。
TwittterやFacebookなどそういう大きなサービスは独自にやっているらしいので置いといて、
私のようにOAuthで認証できるように実装するならどういうフローが標準として良いですか?という問いが出てきたときに、その答えとして登場したのがOpenID Connectというイメージ。
参考: OpenIDの概要
出典：OpenIDの概要 https://www.mhlw.go.jp/content/10800000/000537444.pdf
参考
Discussion