こんにちは、開発3部のKOJIです。
現在、広く一般的に普及している認証としてOpenID Connectがありますが、プログラミングを初めて独自のID・パスワード認証しか作成したことが無い方には少しハードルが高いと思います。
そこで今回は、OpenID Connectの概要について触れておきます。
OpenID Connect (OIDC) は、OAuth 2.0 プロトコルを拡張した認証プロトコルです。（OIDC以外の認証プロトコルとしては、SAMLなどがあります。）
クライアント（ウェブサイトやアプリ）が、認証サーバー（IdP - Identity Provider）によるユーザー認証の結果を検証し、ユーザーの基本的なプロフィール情報を取得することを可能にします。
主な特徴
- OAuth 2.0がベース: OIDCはOAuth 2.0の認可フレームワークの上に構築された認証レイヤーです。
- IDトークン: ユーザーの認証情報をJSON Web Token (JWT) 形式でカプセル化した「IDトークン」を使用します。これにより、クライアントはユーザー情報を安全に受け取ることができます。
- 標準化: 仕様が公開されており、多くのIdP（Google, Microsoft, Auth0など）でサポートされているため、相互運用性が高いです。
- シンプル: REST/JSONをベースにしているため、SAMLなどの古いプロトコルに比べて実装が容易です。
登場人物
- エンドユーザー: 認証を受ける本人。
- リライング・パーティ (RP - Relying Party): IdPに認証を要求するクライアント（自身が作成しているウェブサイトやアプリなど）。
- OpenIDプロバイダ (OP - OpenID Provider): ユーザーを認証し、RPに対してユーザー情報を提供するIdP。（Google, Microsoft, Auth0など）
認証フロー
認証フローは、Authorization Code Flow、Implicit Flow、Hybrid Flowなど複数あり、アプリケーションの構成やセキュリティを考慮して認証フローを決めます。
最も一般的で安全なフローであるAuthorization Code Flowは以下のとおりです。
- 認証要求: ユーザーがRP（例: ECサイト）でログインしようとすると、RPはユーザーをOP（例: Google）にリダイレクトさせる。
- ユーザー認証: ユーザーはOPのログイン画面でIDとパスワードを入力し、認証を行う。
- 認可コード発行: 認証が成功すると、OPは認可コードを発行し、ユーザーをRPの指定URL（リダイレクトURI）にリダイレクトさせる。
- トークン要求: RPは受け取った認可コードを使い、バックエンド通信でOPのトークンエンドポイントに「IDトークン」と「アクセストークン」を要求する。
- トークン発行: OPは認可コードを検証し、問題がなければIDトークンとアクセストークンをRPに発行する。
- 認証完了: RPはIDトークンを検証し、中に含まれるユーザー情報（ユーザーIDなど）を取得して、ユーザーのログインを許可する。
セキュリティ対策
セキュリティ対策として、state(CSRF対策), nonce(リプレイ攻撃対策), PKCE(認可コード横取り対策)などがあり、RP側とOP側の両方で対応が必要です。
まとめ
OpenID Connectは、OAuth 2.0の認可の仕組みを基盤としながら、アプリケーションが必要とする「認証」の機能を追加した、現在の標準的な認証プロトコルです。
クロノスでポジティブな社員と「まじめに、たのしく、おもしろく」働きませんか？新しい仲間を大募集中です！
