この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
Auth0のRules記事第二弾(個人)です。
今回は、Rulesでid_token
のクレームにuser_metadata
を追加する機能を試してみました。そもそもRulesでどのような情報が取れるのか知りたい方は、過去記事を読んでみてください。
名前空間について
id_token
には名前空間が存在し、任意のクレームを追加する上でルールが存在します。
詳細は、Auth0ドキュメントのUser profile claims and scopeに記載されておりますが、簡単に要約、翻訳すると以下の通りです。
名前空間のルール
Auth0は「OIDC仕様でカスタムクレーム識別子は衝突耐性があることを推奨している」ことを受けて、以下のような仕様になっています
- HTTP/HTTPSのURLを名前空間識別子として、任意の数の使用可能 (※1)
- 名前空間のURLはあくまで識別子、Auth0によって呼び出されることはない (※2)
- HTTP/HTTPS名前空間のないカスタムクレームは、トークンから除外される
※1 auth0.com、webtask.io、webtask.runはAuth0ドメインであるため、名前空間識別子として使用不可
※2 実際のリソースである必要もない
id_tokenにuser_metadataを追加してみる
構成
- クライアントアプリ
Auth0のSINGLE PAGE APPLICATIONのAngularサンプルを利用 -
クライアントアプリに渡された
id_token
の確認方法
Chrome Developer Tools
のNetworkタブで、流れてきたid_token
をデコード
user_metadataを設定する
Rulesコードを書く
function (user, context, callback) {
const namespace = 'https://myapp.example.com/';
console.log(`user_metadata is ${user.user_metadata}`);
console.log(`context.idToken before : ${JSON.stringify(context.idToken)}`);
context.idToken[`${namespace}user_metadata`] = user.user_metadata;
console.log(`context.idToken after : ${JSON.stringify(context.idToken)}`);
callback(null, user, context);
}
結果
Rulesなしの場合のid_token
のPayloadデコード結果
{
"nickname": "xxxxxx",
"name": "xxxxxx@gmail.com",
"picture": "https://s...",
"updated_at": "2019-08-25T08:21:36.910Z",
"email": "xxxxxx@gmail.com",
"email_verified": true,
"iss": "https://{テナントのドメイン}.auth0.com/",
"sub": "auth0|5...",
"aud": "Cf...",
"iat": 1566721299,
"exp": 1566757299,
"nonce": "gS4..."
}
Rulesありの場合のid_token
のPayloadデコード結果
{
"https://myapp.example.com/user_metadata": { // <-- 追加されている
"foo": "bar"
},
"nickname": "xxxxxx",
"name": "xxxxxx@gmail.com",
"picture": "https://s...",
"updated_at": "2019-08-25T09:21:08.414Z",
"email": "xxxxxx@gmail.com",
"email_verified": true,
"iss": "https://{テナントのドメイン}.auth0.com/",
"sub": "auth0|5...",
"aud": "Cf...",
"iat": 1566724870,
"exp": 1566760870,
"nonce": "Lt..."
}
最後に
本記事の手法を活用することで、Rules内でサードパーティ製APIや既存の社内システムのAPIを実行しid_token
に含めることも勿論可能です。
クライアントアプリが知っておくべき情報を、極力Rules経由でid_token
で渡すことにより、クライアント側で無駄な通信をしなくてよくなるため、活用していきたいところです。