OpenID Connect入門

OpenID Connect入門
2020/06/10
1

筆者の自己紹介
• 土岐孝平
• 合同会社現場指向
– システム開発の支援
• Java、Spring Framework
– メモラキー
• 軽快でシンプルなメモアプリ
– https://www.memorarchy.com
• 書籍の執筆
– Spring入門
2
[改訂新版]Spring入門

本資料の対象者
• OAuth2.0やOpenIDを調べたことがあるが、い
まいちピンと来ていない
• OAuth2.0は知っているが、OpenIDとの違い・
関係がわからない
• 具体的にどのようなデータがやりとりされてい
るのか知りたい
3

アジェンダ
• OpenID Connectの概要
• フローの種類
• OIDCの利用シーン
• JWTについて
• 認可コードフローの詳細
• ライブラリの利用
• 参考資料
4

OpenID Connectとは？
• 認証・認可のための標準化されたHTTPベー
スのプロトコル
• OpenID Foundationという組織が2014年に公
開
• 認可のプロトコルであるOAuth2.0を拡張して
いる
6
【補足】
「OpenID」と「OpenID Connect」は、指してるものが異なる。「OpenID」は2005年から
存在するプロトコルで、OAuth2.0の拡張ではない。「OpenID Connect」は2014年に
公開され、OAuth2.0を拡張している。いずれもOpenID Foundationという組織が促
進している。

OAuth2.0とは？
• 2013にIETFが発表した認可のためのプロトコル
• アクセス権の委譲を安全に行うことができる
– アクセス権の委譲とは？
• あるシステムへのアクセス権を、別のシステムに与えること
7
システムA システムB
「システムBの私のデータに
アクセスしていいですよ」 Xさんの
データ
Xさん
Xさんのデータに
アクセス
【注意】
OAuth2.0の認可は、ユーザに対する認可ではなく、
アクセスする側のシステム(ここではシステムA)に対する認可

OAuth2.0が登場する以前のやり方
8
• ユーザのID・パスワードを、アクセスする側のシステ
ムに入力
– 悪意のあるシステムの場合は危険
– アクセスの種類(読込・書込など)が不明
Yelpというクチコミサイトの画面(2008年ごろと思われる)

OAuth2.0の仕組み
• アクセストークンとよばれるワンタイムパスワードのような情
報を使用する
– ①ユーザがアクセスを承諾する
– ②アクセストークンを発行する
– ③アクセストークンを含めてリクエストする
– ④アクセストークンの有効性やアクセスの種類をチェックする
9
システムA システムB
①
②
③
④

OAuth2が登場した後のやり方
• アクセスされる側の
システムの画面で
承諾を行うことがで
きる
• アクセスの種類が
確認できる
10
アクセスの種類が
示されている
アクセスされる側のシス
テムの画面

認証の仕組みとしてのOAuth2.0
• 認証の仕組みとしてOAuth2.0を使うケースもある
– アクセストークンが発行されたということは、ユーザはアク
セスされる側のシステムで認証されていることになる
– アクセスされる側のシステムで認証されてれば、自前アプ
リの認証もOKとする
11
自前アプリ GoogleやFacebookなど
承諾(ユーザの認証が既に行われている)
ユーザ
【メリット】
・自前システムで認証の仕組み用意
しなくてよい
・ユーザにとっては、新しくアカウント
登録する必要がない

認証の仕組みとしてのOAuth2.0の問題
• 認証時の情報(認証の日時や手段など)や、
ユーザの情報(ユーザの名前やメールアドレ
スなど)が不明
– 独自の実装で対応する必要があった
12
自前アプリ GoogleやFacebookなど
ユーザ
・いつ・どうやって認証した
のだろう？
・誰が利用しているのだろう
？
利用
承諾
発行

OpenID Connectによる拡張
• 認証時の情報や、ユーザ情報を取得するた
めの仕様を追加
– IDトークンという概念を追加
• IDトークンの中に認証時の情報を含めることができる
– ユーザ情報を取得するための仕組みを追加
• 名前やメールアドレスなどの基本的な情報は項目名
が定められている
13ユーザ
承諾
＆
IDトークン
ユーザ情
報を取得
・以降、本資料では、OpenID Connectの
ことを、「OIDC」と記載する。
・また、OIDCの意味の中に、暗黙的に
Auth2.0を含む。

登場人物の役割と用語
役割 OAuth2.0の用語 OIDCの用語本資料での呼び方
システムを使うユーザ Resource Owner End User ユーザ
ユーザが操作する端
末
User Agent -
(定義してない)
User Agent
トークンを発行するシ
ステム
Authorization Server OpenID Provider Authorization Server
トークンを発行しても
らうシステム
Client Relying Party Client
トークンを使ってアク
セスされるシステム
Resource Server -
(定義してない)
Resource Server
14
【補足】
・Resource ServerとAuthoriation Serverは、一緒のシステムかもしれないし、
別のシステムかもしれない(どちらでもよい)

フローとエンドポイント
• OIDCでは、決められた「フロー」に従って、「エ
ンドポイント」にアクセスしながらデータをやり
とりし、トークンを発行する
• フロー
– トークンを発行する際のデータのやり取りの流れ
。利用シーンに合わせて、いくつかの種類がある
• エンドポイント
– データをやり取りする際のリクエストを受け付ける
口。いくつかの種類がある。フローによって利用
するもの・利用しないものがある
16

フローの種類
名前特徴主なClientの種類
認可コードフロートークンを発行する前に、認可コードを
やりとりすることで安全性を向上する
Webアプリ(MPA※1・SPA)
インプリシットフロー認可コードを使わずにトークンを発行
する。リフレッシュトークンを利用でき
ない※2。現在は推奨されていない※3。
Webアプリ(SPA)
ハイブリッドフロー認可コードを取得するタイミングでID
トークン・もしくはアクセストークンを取
得することが可能
？（筆者が利用シーンをイメージ
できていないため）
クライアント
クレデンシャルフロー
ClientのID・パスワードを使ってトーク
ンを取得する。発行されるアクセストー
クンはユーザと紐づかない。
バッチアプリ、他システムと連携
するバックエンドのシステム
リソースオーナーパスワード
ユーザのID・パスワードを使ってトーク
ンを取得する。ClientにユーザのID・パ
スワードを渡す必要がある。
Authorization Serverの組織の公
式アプリ(例えば、SNSサイトの公
式スマフォアプリなど)
17
※1 Multi Page Application。リクエスト毎にサーバ側でHTMLを生成する昔ながらのWebアプリ
※2 アクセストークンをリフレッシュ(有効期限を更新するなど)する際に使用するトークン
※3 参考： https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09

エンドポイントの種類
名前役割提供元関連するフロー
認可エンドポイントフローを開始するために必要な
情報(ClientのIDなど)を
Authorization Serverが受け取る
・Authorization
Server
・認可コードフロー
・インプリシットフロー
・ハイブリッドフロー
リダイレクト
エンドポイント
Authorization Serverが発行した
認可コードもしくはトークンを
Clientが受け取る
・Client
（SPAの場合は
Webサーバ）
・インプリシットフロー
トークン
IDトークン・アクセストークン・リフ
レッシュトークンを発行する
・Authorization
Server
・クライアントクレデンシャルフ
ロー
・リソースオーナーパスワード
ユーザ情報
ユーザ情報を提供する・Authorization
Server
・クライアントクレデンシャルフ
ロー以外の全てのフロー
トークン検証
アクセストークンの有効性を検証
する
・Authorization
Server
・全てのフロー
18

認可コードフロー(MPA)
19

認可コードフロー(SPA)
20

インプリシットフロー(SPA)
21

クライアントクレデンシャルフロー
22

リソースオーナーパスワードクレデンシャルフロー
23

アクセストークンの有効性の確認方法
• 主な２つの確認方法から選択することができる
• ①トークン検証エンドポイントで確認する
– 〇無効になったアクセストークンをリアルタイムに検知で
きる
– ×都度Authorization Serverに問い合わせるため負荷が
高い
• ②アクセストークンをAuthorization Serverが電子署
名し、Resource Serverが署名や有効期限などを検証
する
– 〇都度Authorization Serverに問い合わせる必要がない
– ×無効になったアクセストークンをリアルタイムで検知で
きない
24

利用シーンの主な種類
• 自前のアプリを作るにあたって、以下の利用
シーンが想定できる
– SNSサイトなどのデータを利用したい
– 認証をSNSサイトなどに任せたい
– シングルサインオンのプラットフォームにしたい
– バックエンドのシステム間で安全にAPIを呼び出し
たい
26

SNSサイトなどのデータを利用したい
• 例えば、Facebookの友達やGoogleのコンタク
ト情報などを、自前アプリで利用する
27
自前アプリ
(Client)
GoogleやFacebookなど
(Authorization Server・Resource Server)
承諾
ユーザ
利用
友達やコンタクト情報を取得

認証をSNSサイトなどに任せたい
• 自前アプリで認証の仕組みを作るのは大変
なので、SNSサイトなどに任せる
28
自前アプリ
(Client)
GoogleやFacebookなど
(Authorization Server・Resource Server)
ユーザ
利用

シングルサインオン※のプラットフォームにしたい
• Authorization Serverを調達し、シングルサイ
ンオンのプラットフォームにする
29
自前アプリB
(Client) Authorization Server
ユーザ
利用
自前アプリA
(Client)
利用
※厳密には、１回のログイン操作で複数のアプリを利用できることを指すが、OIDC
の場合Client毎に承諾が必要となる。ここでは、1つのアカウントで複数のアプリを
利用できることを指す

Authorization Serverの調達について
• Authorization Serverを自前で実装してもよい
が、既存の製品やサービスを利用するのが
無難と思われる
• 製品やサービスの例
– 自前のサーバにインストールする場合
• Keycloak(https://www.keycloak.org/)
• OpenAM(https://www.openam.jp/)
– クラウドのサービスを利用する場合
• Auth0(https://auth0.com/)
• okta(https://www.okta.com/)
30

バックエンドのシステム間で安全にAPIを呼び出す(1/2)
• ユーザの情報が必要なければ、クライアントクレデ
ンシャルフローでトークンを取得
31
自前API
(Resource Server 兼 Client)
Authorization Server
アクセス
自前アプリ
(Client)
自前API
(Resource Server)
アクセス
アクセス
自前API
(Resource Server)
トークン
トークン

バックエンドのシステム間で安全にAPIを呼び出す(2/2)
• ユーザの情報が必要であれば、認可コードフローや
インプリシットフローでトークンを取得
32
自前API
(Resource Server)
Authorization Server
アクセス
自前アプリ
(Client)
自前API
(Resource Server)
アクセス
アクセス
自前API
(Resource Server)
トークン
ユーザ
承諾

JWT(JSON Web Token)とは？
• IETFによって標準化されたデータ形式
– OIDCに特化したものではない
• クレイムとよばれるさまざまな情報をJSON形式で表現
– 一般的なクレイムは項目名が定義されている
• 例)「iss」というクレイムは、発行元(issuer)を表す
• Base64URLでエンコードするため、空白の制約があるような
状況(HTTPのヘッダやクエリー文字列など)で使うことができ
る
• JWSとJWEという２つの形式があり、OIDCのIDトークンはJWS
形式となる
• JWS(JSON Web Signature)の特徴
– 電子署名されるため、データに信頼性(発行元の証明、改ざん防止)
がある
– 「ヘッダ」「ペイロード」「電子署名」の３つで構成される
34

JWT(JWS)のデータ形式
3535
{"typ":"JWT",
"alg":"HS256"}
【ヘッダ】
{"iss": "https://server.example.com",
"sub": "24400320",
"aud": "s6BhdRkqt3"}
【ペイロード】
Base64URLエンコーディング
eyJ0eXAiOiJKV1QiLA0KICJhbGci
OiJIUzI1NiJ9
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA
4MTkzODAsDQogImh0dHA6Ly9leGFtcGxl
LmNvbS9pc19yb290Ijp0cnVlfQ
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzO
DAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb
290Ijp0cnVlfQ
.
dBjftJeZ4CVP-
mB92K27uhbUJU1p1r_wW1gFWFOEjXk
【最終的なデータ】ドット「.」でつなげる
電子署名

【参考】JWTのデコードに便利なサイト
36
https://jwt.io
デコードされた結果
JWTの値

JWTとOIDC
• OIDCのIDトークン(認証時の情報を含む)は、
JWT(厳密にはJWS)形式にするというルール
になっている
• アクセストークンはJWT形式にするルールは
ないが、アクセストークンの有効性を検証す
る際に電子署名を使う場合はJWT形式にする
37

IDトークンの主なクレイム
38
項目名内容
iss 発行元を特定する識別子
sub ユーザを特定する識別子
aud IDトークンの読者。client_idが設定される。
exp 有効期限。1970/1/1からの経過秒数で表わされる。
iat 発行日時。1970/1/1からの経過秒数で表わされる。
auth_time 認証が行われた日時。1970/1/1からの経過秒数で表わ
される。
acr 認証の手段を表す値

認可コードフローの詳細
39

本セクションについて
• OIDCで最も代表的なフローと思われる認可コ
ードフローについて、具体的なデータを示しな
がら説明する
• Clientは、SPAのWebアプリを想定する
40

【再掲】認可コードフロー(SPA)
41

認可リクエスト(1/2)
• Authorization Serverに対して、フローを開始するための情報
をClientから渡す
• リクエストのパスの値はAuthorization Serverが提供する
– OIDCの仕様上はパスの値は決まっていない
• HTTPメソッドはGETもしくはPOST
• 主なパラメータ
42
パラメータ名説明値
scope アクセスの種類を指定
空白区切りで複数指定可能。仕様で
定義されてるもの(後述)と、任意に定
義したものを指定できる。「openid」
は必須
response_type レスポンスの種類(後述) 「code」
client_id
Clientを一意に識別するためのID。
Authorization Serverに事前に登録して
おく。
登録したClient ID
redirect_uri
ClientのリダイレクトエンドポイントのURL。
Authorization Serverに事前に登録して
おく。
リダイレクトエンドポイントのURL

認可リクエスト(2/2)
• リクエストのサンプル
• 定義済みの主なスコープ
43
https://server.example.com/authorize?
response_type=code
&scope=openid profile email
&client_id=s6BhdRkqt3
&redirect_uri=https://client.example.org/app.html
項目名内容
sub ユーザを特定する識別子
name 名前
profile プロフィールのURL
picture プロフィール画像のURL
email メールアドレス
phone_number 電話番号
address 住所

response_typeの指定
44
• 認可リクエストのレスポンスの種類を、
response_typeパラメータで指定
• Response_typeの指定によってフローの種類
が変わる
response_typeの値レスポンスの内容使用されるフロー
code 認可コード認可コードフロー
id_token IDトークンインプリシットフロー
id_token token IDトークンとアクセストークン
code id_token 認可コードとIDトークンハイブリッドフロー
code token 認可コードとアクセストーク
ン
code id_token token 認可コードとIDトークンとアク
セストークン

SPAのClientシークレット
• Authorization Serverは、認可リクエストの送信元が、正しい
Clientかどうかを特定する必要がある(Clientのなりすましを防
止)
• 正しいClientしか知りえないClientシークレットを送信するのが
確実だが、SPAの場合、ユーザエージェント上にClientシーク
レットの値が保有されることになるため、漏洩の危険が高い
• SPAのClientの場合は、Clientシークレットは使用しない。レス
ポンスのリダイレクトURLをAuthorization Serverに事前に登録
しておくなどで、Clientのなりすましを防止する(悪意のあるサ
イトへリダイレクトされることがない)
45

認可レスポンス
• 認可コードが返される
• Clientのリダイレクトエンドポイントへリダイレクトする
– ステータスコード302など
• リダイレクトURLの必須のパラメータ
46
code 認可コード Authorization Serverが生成した認可コード
HTTP/1.1 302 Found
Location: https://client.example.org/app.html?
code=SplxlOBeZQQYbYS6WxSbIA
【サンプル】

リダイレクトエンドポイント
• 承諾の結果をClientが受け取るためのエンド
ポイント
• 認可コードフローの場合は、パラメータで認可
コードを受け取る
47
GET /app.html?
code=SplxlOBeZQQYbYS6WxSbIA
HOST: client.example.org
【サンプル】

認可コードをClientが取得する方法
• リダイレクト先からClientのJSプログラムがダ
ウンロードされた後、JSプログラムが現在の
URLから認可コードを取得すればよい
– Webサーバで取得しなくてもよい
48
・・・?code=ｘｘｘ
ここで取得

トークンリクエスト
• IDトークン/アクセストークン/リフレッシュトークンを取得するためのリクエ
スト
• リクエストのパスの値はAuthorization Serverが提供する
• HTTPメソッドはPOST
• 必須のパラメータ
49
grant_type トークンを取得する手段「authorization_code」
code 認可コード認可コードの値
client_id
Clientを一意に識別するID。事前に
Authorization Serverに登録しておく。
登録したID
redirect_uri
Clientのリダイレクトエンドポイントの
URL。認可リクエストのときと同じ値を
指定する。
リダイレクトエンドポイントのURL

トークンリクエストのサンプル
50
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&client_id=s6BhdRkqt3
&redirect_uri=https://client.example.org/app.html

トークンレスポンス
• IDトークン・アクセストークン・リフレッシュトー
クンをJSON形式で返す
• 主な属性
51
属性名説明値
id_token IDトークン生成されたIDトークンの値
access_token アクセストークン生成されたアクセストークンの値
token_type リソースサーバにアクセストークンを
送信するときの手段
「Bearer」※
refresh_token リフレッシュトークン生成されたリフレッシュトークンの値
expires_in
アクセストークンの有効期間(本レス
ポンスが作られてからの経過秒数)
有効期間の秒数
※HTTPのリクエストヘッダに「Authorization: Bearer {トークンの値}」を指定する。

トークンレスポンスのサンプル
52
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"access_token": "SlAV32hkKG",
"token_type": "Bearer",
"refresh_token": "8xLOxBtZp8",
"expires_in": 3600,
"id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.ewogImlzc
yI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4Mjg5
NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZ
fV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEzMTEyODA5Nz
AKfQ.ggW8hZ1EuVLuxNuuIJKX_V8a_OMXzR0EHR9R6jgdqrOOF4daGU96Sr_P6q
Jp6IcmD3HP99Obi1PRs-cwh3LO-p146waJ8IhehcwL7F09JdijmBqkvPeB2T9CJ
NqeGpe-gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7Tpd
QyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF_m0_N0YzFC6g6EJbOEoRoS
K5hoDalrcvRYLSrQAZZKflyuVCyixEoV9GfNQC3_osjzw2PAithfubEEBLuVVk4
XUVrWOLrLl0nx7RkKU8NXNHq-rvKMzqg"
}

ユーザ情報リクエスト
• ユーザ情報を取得する
• アクセストークンをリクエストに含める
– ヘッダで「Authorization: Bearer {トークンの値}」を
指定する
• リクエストのパスの値はAuthorization Server
が提供する
• HTTPメソッドはGETもしくはPOST
• サンプル
53
GET /userinfo HTTP/1.1
Authorization: Bearer SlAV32hkKG
アクセストークン

ユーザ情報レスポンス
• ユーザ情報をクレイムとしてJSON形式で返す
• 「sub」クライムが必須で、IDトークンの「sub」の値と
一致する
• サンプル
54
HTTP/1.1 200 OK
{
"sub": "248289761001",
"name": "Jane Doe",
"given_name": "Jane",
"family_name": "Doe",
"preferred_username": "j.doe",
"email": "janedoe@example.com",
"picture": "http://example.com/janedoe/me.jpg"
}

Resource ServerのAPIの呼出
• アクセストークンを使って、Resource Serverの
任意のAPIを呼び出す
• アクセストークンは、通常は「Bearer Token」と
呼ばれる方法でリクエストに含める
– HTTPの「Authorization」ヘッダの値で「Bearer {ア
クセストークンの値}」を指定する
– サンプル
55
GET /friends HTTP/1.1
Authorization: Bearer mF_9.B5f-4.1JqM
アクセストークン

リフレッシュリクエスト
• リフレッシュトークンを使って、アクセストークンをリフレッシュ
する
– 有効期限が切れた場合(もしくは切れる前)に、再発行することができ
る
• トークンエンドポイントを使用する
• HTTPメソッドはPOST
• 必須のパラメータ
• サンプル
56
grant_type トークンを取得する手段「refresh_token」
refresh_token リフレッシュトークンリフレッシュトークンの値
POST /token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA

リフレッシュレスポンスのサンプル
57
HTTP/1.1 200 OK
Cache-Control: no-store
Pragma: no-cache
{
"access_token": "TlBN45jURg",
"token_type": "Bearer",
"refresh_token": "9yNOxJtZa5",
"expires_in": 3600
}

ライブラリの利用
• Authorization Serverとして既存の製品やサー
ビスを利用する場合、Clientがトークンを取得
するためのデータのやり取りは、その製品が
ライブラリとして提供していることが多い。
– ライブラリを利用すると、エンドポイントへのアク
セスはライブラリが行ってくれるため、最小限の
設定を行うだけでよい
• Resource Serverを実装する際は、汎用的なラ
イブラリを利用することで、アクセストークンの
有効性の確認などをライブラリに任せること
ができる
59

Client(SPA)の実装の例(1/2)
• KeycloakのJSライブラリの場合
60
<html>
<body>
<button onclick="callHello()">call hello</button>
<script src="keycloak.js"></script>
<script>
var keycloak = Keycloak(
{
url: ‘Authorization ServerのURL',
realm: ‘Clientが属するリーム※KEYCLOAKの用語',
clientId: ‘Client Idの値'
}
);
keycloak.init(
{ onLoad: 'login-required'}
).success(function (authenticated) {
・・・
}).error(function (error) {
・・・
});
・・・
ログインしていない場合は、自動的に
Keycloakのログイン画面が表示される
※利用イメージを伝えるのが
目的なので簡略化している

Client(SPA)の実装の例(2/2)
• Resource ServerのAPIの呼び出し
61
function callHello() {
var url = ‘Resource ServerのAPIのURL';
var req = new XMLHttpRequest();
req.open('GET', url, true);
req.setRequestHeader('Accept', 'application/json');
req.setRequestHeader('Authorization', 'Bearer ' + keycloak.token);
req.onreadystatechange = function () {
if (req.readyState == 4) {
if (req.status == 200) {
alert('MSG='+req.response);
} else if (req.status == 403) {
alert('許可されてません');
}
}
}
req.send();
}
前スライドで定義した変数から、
アクセストークンを取得している

Resource Serverの実装例(1/2)
• JavaのSpring Frameworkを利用した場合
• 設定回り
62
@EnableWebSecurity
public class OidcResourceServerConfig extends WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
http
.authorizeRequests()
.anyRequest()
.authenticated()
.and()
.oauth2ResourceServer()
.jwt()
.jwkSetUri(
"http://localhost:9999/auth/realms/oidc-sample/protocol/openid-connect/certs");
}
}
JWTの電子署名の検証で使用する公開鍵を取
得するためのAuthorization Server上のURL

Resource Serverの実装例(2/2)
• APIの実装
63
@RestController
public class HelloController {
@GetMapping("/hello")
public String hello(@AuthenticationPrincipal Jwt token) {
String msg =
“sub=“ + token.getSubject()
+ " email=" + token.getClaims().get("email")
+ " scope=" + token.getClaims().get("scope");
return msg;
}
}
アクセストークンの情報を
参照できる

参考資料の一覧
65
資料場所
OpenID Connectの仕様 https://openid.net/specs/openid-connect-core-1_0.html
OAuth2.0の仕様 https://tools.ietf.org/html/rfc6749
セキュリティに関するベスト
プラクティス
※インプリシットフローは非
奨励と記載
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09

OpenID Connect入門

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à OpenID Connect入門

Similaire à OpenID Connect入門 (20)

Plus de 土岐孝平

Plus de 土岐孝平 (16)