こんにちは。rendaman0215です。
先日、社内で新しいOpenID Connectに準拠した認証基盤を導入しました。
反響もあり色々なプロダクトで使ってもらえるようになっている一方で、でなにしたらいいのって話がよく出ます。
そこで関係者がOpenID Connectを利用するうえで気になりそうなポイントをまとめてみました。
概要
OpenID Connectとは、認可に特化したOAuth2.0を拡張したもので、認証に関する仕様を策定しています。
OAuth2.0は「RFC6749」で定義されているものの、OpenID ConnectはRFCで定義されていません。
登場人物
- Relying Party
- OAuthでいうところのClient。
- 認証機能を導入したいアプリケーション。
- OpenID Providerに対してEnd-Userの認証とIDトークンを要求する。
- OpenID Provider
- OAuthでいうところのAuthorization Server。
- 認証機能を提供し、リクエストに対してIDトークンを返却する。
- End-User
- OAuthでいうところのリソースオーナー。
- アプリケーションを利用するユーザ。
処理概要
OpenID Connectは、大まかに以下の流れで行います。
1. RelyingParty が OpenID Provider (OP) にリクエストを送る。
2. OP は End-User を認証し, 認可を受ける。
3. OP は ID Token および (通常は) Access Token を返す。
4. RP は Access Token を添えて UserInfo Endpoint にリクエストを送る。
5. UserInfo Endpoint は End-User の Claim を返す。
IDトークン
OpenID Connectの肝となる部分です。
OAuthとの最大の違いは、このIDトークンが払い出されることです。
IDトークンとは、OPが払出しRPがEnd-Userを認証するために使うものです。
IDトークンは、JWT形式で提供されます。
なおネイティブアプリなどではない限り、極力IDトークンはサーバサイドで管理するのがセキュリティ的に望ましいです。
JWT
JWT（JSON Web Token）は、はRFC7519で定義されている表現形式で、ヘッダ・ペイロード・署名の3部構成となっています。
Base64URLエンコードされているため、Base64URLデコードすることで読むことができます。
- ヘッダ部：暗号化アルゴリズムやトークンの種類を記載
- ペイロード部：IDトークンに関わる各トークンを記載
- 署名部：秘密鍵とヘッダ部のアルゴリズムにより署名を作成し、改ざんを検知できる仕組みのために記載
クレーム
ペイロードに含まれるデータ。
OpenID Connectでは、以下のクレームを定義しています。
| クレーム名 | 意味 |
|---|---|
| iss | IDトークンの発行者（通常はURL形式で表す） |
| aud | IDトークンを利用するRPのクライアントID |
| sub | End-Userの識別子 |
| iat | いつ発行されてか |
| exp | いつまで利用できるか |
| nonce | リプレイアタック防止のためのランダム文字列 |
認証フロー
OpenID Connectには、以下の3つのフローがあります。
- 認可コードフロー
- インプリシットフロー
- ハイブリッドフロー
この中でOpenID Connectを使う上で基本的に選ばれる認可コードフローについて解説します。
認可コードフロー
RPが実装すべき機能
- ログインを試みているエンドユーザをOPへ遷移させる
- OPから認可コードを受け取り、OPのトークンエンドポイントへリクエストし、IDトークンを取得
- IDトークンの検証
- IDトークンとエンドユーザを紐付ける機能（IDトークンをサーバサイドで管理する場合）
OIDCを提供しているサービス
Auth0などのIDaaSを用いることで、OPの機能を自前で実装せずに認証基盤を作成することができます。
OIDCのOP機能を自前で実装するとなかなかにセキュリティリスクや開発個数がかかるので、金銭面的に選択肢に入るなら検討されてもいいかもです。
また、これらのサービスでは、RPの機能もSDKなどで提供されていることが多いので使いやすいです。
（補足）OAuth2.0との違い
OAuthでの認証では、Authサーバがアクセストークン（認可を表す）をクライアントに払出し、認可内容から逆算して認証を行なっていました。
OIDCでは、OPが認証を表すIDトークンを払出すため、認証においてはよりセキュアです。
大きな違いは、ペイロード部のaudクレームでRPを記載しており、RP以外では使用できないようになっていることですね。
参考資料
今回の記事は公式の資料をもとに作成しています。
https://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html