OAuth2.0 と OpenID Connect との関係についても見ていきます。
OAuth2.0 では、OpenID Connect の仕様を取り入れているので、おのずと使えます。
Google のOpenID Connect についての解説では、
「GoogleのOAuth 2.0 APIは、認証と認可の両方に使用できます。」
とあります。OAuth2.0 は「認可」つまり、「私のどこどこの情報は見て良い」というような許可や権限も含んでいますので、
単純な「認証」つまり「これは本当に私です」という範囲を超えています。
code for access token and ID tokenhttps://accounts.google.com/o/oauth2/v2/auth?
client_id=424911365001.apps.googleusercontent.com&
response_type=code&
scope=openid%20email&
redirect_uri=https://oauth2-login-demo.example.com/code&
state=security_token%3D138r5719ru3e1%26url%3Dhttps://oauth2-login-demo.example.com/myHome&
login_hint=jsmith@example.com&
openid.realm=example.com&
nonce=0394852-3190485-2490358&
hd=example.com
URL は Google+ の認可のものと同じです。
scope が違います。特に、ここでは"openid"と"email"の２つの情報を取得します。(スペースで区切る)
OpenID を要求しているところが、認可を使う場合と異なるところです。
また最低必要なものは、
です。実際に実行してみると、認可画面は表示されず、
正しいパスワードを入力した時点で、リダイレクト先が呼ばれます。
これならば、抵抗は少ないですね。
3.は、CSRFの確認です。
パラメータとして渡されるので、自分で１.で設定していた場合は、同じ値か確認します。
4.でアクセストークンを取得します。手順は Google+ やカレンダーの認可と同じです。
異なるのが、IDトークン("id_token")も返ってきます。
5.でユーザー情報を取得します。
取得した IDトークンですが、JWT という形式で符号化されています。復号すると、いろいろな情報があり、
その中にユーザー情報も含まれています。
復号については、Yahoo!の記事 が判り易かったです。
大事な点は、送られてきた内容が書き換えられた不正なものでない事を"署名"で確認することです。
ユーザー認証としては、これだけで完結します。
6.アプリケーション側で、ユーザー登録処理
正しい情報と判れば、自身のデータベースと照合して、既にユーザー登録があれば続いて処理を実行し、
無ければ、ユーザーの新規登録画面へ進むことになります。
これで完了です。
あれ？何か忘れているような・・・
そうです、アクセストークンを使ってないですね。
リンクの Google の解説では、さらに続きます。
結局は、アクセストークンは追加のユーザープロフィールを取得する為に使うようです。
取得した「IDトークン」の中身は認証元(例えばGoogle)によって返される中身が多少違います。
ある認証元では認証されたという事まではわかるのですが、「誰？」という情報までは含まれない場合もあります。
また、「IDトークンの署名の確認」とさらっと書きましたが、厳密に行おうとすると結構大変なようです。
特に、暗号アルゴリズムを複数サポートしたりとか、自力で行うには少々敷居が高いようです。
Google では、email も含める事が出来るので、email がユーザーIDになるようなシステムでは、
IDトークンの検査だけで終わらすことが出来るかも知れません。
"そうしろ"とは書いてありませんが、結局は、アクセストークンを使って、追加情報として取得するほうが、
簡単だろうと思ったりします。
| « 前頁 | 次頁 » |