OCHaCafe#5 - 避けては通れない！認証・認可 で学んだこと

5948 ワード
oracle OAuth JWT openid_connect oracle テキストリンク

今日は表題の勉強会＠日本オラクルに参加してきたので、復習がてら、学びを記載したいとおもいます。

避けては通れない 認証・認可
https://ochacafe.connpass.com/event/124819/

OAuth

ごくごく一般的な OAuthの認証フロー
1. クライアントを通りして自分のリソースにアクセス
2. ログインして、クライアントにアクセスを許諾(認可)
3. トークンの発行
4. トークンを提示して、リソースにアクセス

フロー図としては下記イメージかと。

エンドポイントは２つある

認可エンドポイント
・認証
・コンセント画面

トークンエンドポイント

フロー図としては、下記イメージ。

1. Oauth のクライアント ID
2. Oauth のフロータイプ認可コードフロー
3. クライアントへのリダイレクト URL
4. 要求するリソースのスコープ
5. State(セッション単位で使う乱数値)

アクセストークンのフォーマットは JWT (JSONWeb Token)
Header、Payload、Signature で構成されている。

会社の先輩に教えてもらったので覚えていたのだが、 JWT のトークンの中身は URL:https://jwt.io/ で decode ができる。

例えば、 Fiddler で アクセス パネル(myapps.microsoft.com)にアクセスして、 Office 365 にアプリケーションにアクセスするまでのログを取って、発行されたトークン(この場合は ID トークンなので OpenID Connect)をコピーする。

これが ID トークンの生データ

これを JWT の Endoded に貼り付ける。
すると以下のような感じで、色分けで、「Header」「Payload」「Signature」に分けてくれる。

Decoded された値をそれぞれ見てみる。
「Header」

「Payload」

名前 意味
sub 誰が(リソースオーナー)
iss 認可サーバー
aud 誰に
scope 何を許可

「Signature」

アクセストークンの検証

・署名検証
・自分自身宛か
・有効期限

認可コードを奪われると、認可コードは誰でもアクセス トークンを取得できる(パブリッククライアントの場合)

・クライアントを認証できないため、認可コードを盗難されたら、容易にアクセストークンを取得されてしまうリスクがある。

OAuth のフローの種類

・認可コードフロー
・インプリシットフロー
・リソース・オーナー・クレデンシャル・フロー
・クライアント・クレデンシャル・フロー
・アサーション・フロー
・デバイス・コード・フロー

Oauth のフローが6種類もあるなんて知らなかった。
Azure AD はどのフローなんだろうか。

とおもったらここにめちゃくちゃ詳しい公開情報があった。
Microsoft ID プラットフォームのアプリケーションの種類
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/develop/v2-app-types

あと Authlete 社の代表の方のこちらの記事もわかりやすいです。

OAuth 2.0 全フローの図解と動画
URL:https://qiita.com/TakahikoKawasaki/items/200951e5b5929f840a1f

OpenID Connect

ID トークンをクライアントが検証してユーザーを識別する、なんでできるのか、 sub、Aud(宛先がクライアントになる)、有効期限、署名

※確かに自分向けに発行されたトークンであることが判別できるので。
アクセストークンの場合は、Aud(宛先)がリソースサーバー宛なので自分宛てなのか判別ができない。

特徴

scope が openid に固定されている
nonce はOpenID connect では必須
nonce はスプレーアタック対策

違いは aud(audience)が違う
クライアントサイド 宛先がクライアント ID になる

アクセストークンのaud はリソースサーバー→ Oauth
ID トークンの aud はクライアント → OpenID Connect

Oracle Identity Cloud Service

SAML、 Oauth2.0,OpenID,Connect SCIM など標準技術、標準規格に対応

感想

感じたのは、OAuth でも OpenID Connect でもトークンの中身は見られるようなった方がいいと思いました。

あと気になったのが、署名の検証の方法について。
Header と Payload を使って行うのは分かるけど、どうやって検証しているのかがまだ理解できていないことが分かった。

最後まで見ていただきありがとうございました。

※参考URL 一覧
https://qiita.com/TakahikoKawasaki/items/200951e5b5929f840a1f
https://docs.microsoft.com/ja-jp/azure/active-directory/develop/v2-app-types
https://jwt.io/