イチカラ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を使え！
これは本当にその通りで、OAuth2.0は認可の仕組みであり、認証の仕組みではない。
しかし、OAuth2.0を利用した認証の仕組みを色々な人が作り始めたら、統一性がなくなって混乱も起きやすい。
色々な人がOAuth2.0を利用した認証の仕組みを考えていた過渡期を経て、OIDCを標準的な仕様としましょうという現在に至っています。
私のようにOAuthをベースに認証できるように実装するならどういうフローが標準として良いですか?という問いが出てきたときに、その答えの1つとして登場したのがOpenID Connectというイメージです。
参考: OpenIDの概要
出典：OpenIDの概要 https://www.mhlw.go.jp/content/10800000/000537444.pdf
参考
Discussion