2OIDCtechritouです。某イベントのこの辺で出てくる質問に回答してみました。OAuthとは目的/用途が異なる。OIDCとの比較では、SAMLをモダンにしたのがOIDCという認識でおk。Signature->JWTみたいな仕様の違いがある。Credentialsといった世の中の動向に追従して現在進行形で拡張仕様やプロファイル、ベストプラクティスの策定が進められている。英語では決まっている。日本語に変換するときにおかしくなったり、IDaaSなどでOIDCをそのまま適用していない場合などで用語の混乱が起こりうる。使えるかどうかは認可サーバーの実装次第。2.0のImplicitはフロントチャンネルを経由するアクセストークンを安全に扱えないので使わないほうが良いのは明らか。OIDCはRP側のパスワード認証と並ぶような立ち位置であり、ログイン状態になった後のセッション管理の部分を置き換えるようなものではない。IDaaSではその部分まで機能として提供しているものもあるが仕様の範囲外と言えるだろう。Managementなどの仕様はIdPのセッションが変わったかどうかの検知、ログアウトの同期といった機能はあるが、主に異なるドメイン間(IdP-RP間)のセッションの整合性を取るためのものであり、RPのセッション管理を代替するものであるとは言えないだろう。実装としては両方あり得ると思うが安全性は当然異なる。ClientTypeの扱いが前者ではPublic、後者はConfidentialになる。前者はSPAだからそこでIDTokenまでとるんだ!と実装するケースと、IDaaSでSPA向けのドキュメントに従った結果そうなったなどのパターンがある。バックエンド側の検証はOIDCの仕様から外れる部分になるので、IDaaSなどの場合はそこをしっかりやる必要がある。後者はトークンを受け取るところまでOIDCの仕様の対象となるので、比較的安全に実装可能。裏では同じことしてるとか、細けぇ話は認可サーバーによるかもしれない。フローになるのでしょうか?という問いに対しては、あくまで独自のショートカット的な立ち位置だと考えるのが良さそう。Flowでクレデンシャルが送られるのは認可サーバーのみ。リソースサーバーには送られない。2.0のImplicitフローがある。その辺り含めて安全にできないのでもう非推奨。2.0の問題とは言えないのではないか。Tokenの特徴を理解した上で安全に実装しましょう。Tokenという概念が必要。それを用いたリクエストの送信者を制限できるという意味合い。Clientの場合はそれができない分、PKCEで認可リクエスト生成時に保持しておいた値を利用しなければならない。この仕組みを入れることで安全にできる。このあたりは認可サーバーの実装に依存。フロントチャンネルでトークンが流れる場合は起こり得る。2.0との違いと言える。Tokenであり、これを利用してアクセストークンを取得するためにはClientCredentialsが必要なところはアクセストークンと違う。サーバー間通信で取得しつつ、どうしてもフロントチャンネル(リダイレクト)で受け取る、フロントエンド-バックエンドでやりとりする場合は署名検証を行う必要がある。気にしなくていいと思う。基本的にクライアントはアクセストークンを検証すべきではない。OIDCが使えない場合はあるかもしれないが、それはもう仕様対象外。あと、検証が必要ない、つまり置き換えが発生しないような実装をしましょう。https://ritou.hatenablog.com/entry/2023/10/08/215035ではまた。https://twitter.com/ritou/status/1713496809694474522ritou今までバッジを頂いた皆様、ありがとうございます。猫のご飯代にします(ΦωΦ)バッジを贈って著者を応援しようバッジを受け取った著者にはZennから現金やAmazonギフトカードが還元されます。バッジを贈るDiscussionritou今までバッジを頂いた皆様、ありがとうございます。Proよくある質問LinksX(Twitter)GitHubメディアキットLegal利用規約プライバシーポリシ。