OCHaCafe#5 - 避けては通れない！認証・認可

Copyright © 2019 Oracle and/or its affiliates. All rights reserved. |
OCHaCafe#5
避けては通れない認証・認可
日本オラクル株式会社
2019年 4月19日

本日の内容
1. 認証・認可の仕組み
- OAuth
- OpenID Connect
2. Oracleの提供する認証・認可サービス
- Oracle Identity Cloud Service
3. OpenID Connectの実装実践とデモ
2
休憩

Copyright © 2019 Oracle and/or its affiliates. All rights reserved. | 3
1.認証・認可の仕組み

認証・認可の“連携“プロトコル
• 認証プロトコル
– IDとパスワードを直接渡して、照合(認証）すること。
– 例： LDAPによる認証（bind操作)
• 認証・認可の“連携“プロトコル
– 自サイトで認証を行わない。
– 他サイトに認証を委託し、結果（認証情報）をもってユーザを識別する。自サイトでは
パスワードを持たなくてよい。
• SAML 1.1, 2.0
• WS-Federation
• OpenID 2.0
• OAuth 2.0
• OpenID Connect 1.0
4

主流のアクセス情報連携のプロトコル
5
SAML 2.0
構造： JSON、RESTベースでメッセージ交換構造：XMLでメッセージ交換
エンタープライズ向け
・開発容易性
・モバイルアプリやSPA（JavaScript）アプリの開発もし易い
社内のSSO（SAML IdP)と連携ニーズ
-ADFSや各社SSOサーバ
-SAMLにしか対応していないことも
他社サービス間での
情報連携
コンシューマー向け用途
・技術自体は確立されている。
標準で容易な実装エンタープライズ向けサービス
でももちろん可
幅広いユースケースに対応できる。
用途次第ですが、今、アプリを開発するならこっちかなぁ、
という感覚
目的：認証情報連携目的：認証情報＋認可情報連携
OpenID Connect

OAuth/OpenID Connectの誕生の背景
• ユーザーのリソースを他のアプリ（パートナーアプリ）に安全に共有したい。
• パートナーアプリにパスワードは教えたくない。
6
従来のWeb SSO
SSOサーバー
アプリA アプリB
アプリAとBが情報を
共有してくれれば便利
なのに
シングルサインオン
？
システム間でユーザーの情報（リソース）の
共有方法
ユーザーのパスワードを登録する
連携用のアプリユーザーを作成
-家計簿サイトに銀行口座のパスワー
ドを教えたいですか？
-ユーザーごとの許可制御が難しい
ユーザーの許可(認可）を
得て、システム間でリソー
スを連携する方式を策定

OAuthの策定：
• ユーザーとシステム間で認可情報を扱うプロトコルとして策定
• Facebook, Yahoo!, AOLやGoogleが主導で策定を開始
• 2007年にOAuth 1.0が策定
• 脆弱性が発見され、2009年にOAuth 1.0として改訂
• 改良版として、2012年 OAuth 2.0が策定された。
– RFC 6749： The OAuth 2.0 Authorization Framework
7

ところで、本日のお題 “認証・認可”
8
認証
認可
IDやパスワードでユーザーを識別（認証処理）
認証処理によって確定された
ユーザー情報を提供
システムがあるユーザーに特定の処理を
行うことを許可
ユーザーがシステムに自分のリソースに操作
を行うことを許可
OpenID Connect

OAuth認証？
• 認可は認証が前提
– 認可サーバは、認可情報（アクセストークン）を発行する際に、まずユーザーの認証を行う。
– 簡単だから認証に使ってしまえ！（＝OAuth認証）
• アクセストークンの悪用のリスク
– Implicitフローでは、悪意のあるアプリがあっさりユーザーのアクセストークンを取得して、悪用が可能。
– アクセストークンは、Bearer型（持参人式）のトークン
• “誰のトークン“ではなく、持っていれば誰でもトークンが使えてしまう。
– 発行されたアクセストークンは、誰でも利用可能
• 成り済まし
9
OAuthの使い方を誤るとリソースサーバーの不正操作、情報の流出が発生
拡張版として、認証のためにOpenID Connectを策定

OAuth と OpenID Connectの関係
10
OAuth OpenID Connect
認可認可認証ユーザー属性
・別なプロトコルではなく、OAuthの拡張がOpenID Connect
・リクエストのパラメータで、OAuthかOpenID Connectとしての動作（レスポンス）が決まる。
OpenID Connect 1.0 は, OAuth 2.0 プロトコルの上にシンプルなアイデンティティレイヤーを付与したもの
である. このプロトコルは Client が Authorization Server の認証結果に基づいて End-User のアイデン
ティティを検証可能にする. また同時に End-User の必要最低限のプロフィール情報を, 相互運用可能かつ
RESTful な形で取得することも可能にする.
OpenID Connect Core 1.0 incorporating errata set 1より
http://www.openid.or.jp/document/ より引用
http://openid.net/specs/openid-connect-core-1_0.html

OAuth / OpenID Connectのシナリオ例
11
街の写真屋さん
リソース・オーナー
ネットの写真サイト
ネットに置いてある
自分の写真を、街の
写真屋さんに印刷し
て欲しい。
写真ファイル
をきれいに
印刷
オーナーさん達
の写真ファイル
を預かってます。

OAuth / OpenID Connectのアクター（登場人物）
12
クライアント
リソースサーバー
認可サーバー
（OAuth Server）
③写真屋さん（クライアント）にア
クセスを承諾（認可）し、承諾書
の引換券（認可トークン）を取得
⑥承諾書（アクセス・トークン）
を提示して、写真ファイル
（リソース）にアクセス
認可を委任
（例：街の写真屋さん）
クライアント
リソース・サーバー
認可サーバー
（例：ネットの写真サイト）
オーナーさんの承諾
書（アクセストークン）
があれば、ファイルを
出しますよ。
⑤引き換え券を
正式な承諾書（アク
セス・トークン）に引
き換え
②承諾があればで
きますよ
①ネットから自分の
写真をダウンロード
して印刷して！
引換券

認可コードフローのシーケンス例
13
(Webブラウザ) 認可サーバー
（写真共有サイト）
クライアント
（写真印刷サイト）
写真共有サイトから画像を参照
認可リクエスト（リダイレクト）
認可エンドポイント
認証（ログイン画面）
認証情報（ID/Pass）
コンセント画面
コンセント応答
認可コードを発行（リダイレクト）
トークンエンドポイント
アクセストークン
リソース（写真一覧）
トークンリクエスト
アクセストークン + リソース取得API（写真一覧）・アクセス
トークン検証
・認可判断
写真サイトから
写真を取得
写真印刷サイトが
次の権限を求め
てきます。
・写真の参照
はいいいえ
ID
PWD
写真一覧の表示

①認可コードリクエスト（OAuthフローの開始）
• リクエスト（GET)
• レスポンス（303 See Other)
14
https://認可サーバー/認可エンドポイント
?client_id=2b0c89ed177d42858d48747f97f03b56
&response_type=code
&redirect_uri=https://localhost:8181/cquotes/return
&scope=get_list view_photo
&state=b621b8e1-eeff-487c-9ef3-ab92a178a720
Location:
https://クライアント/<return_uri>
?code=AQIDBAWaII5T42Sle5s63NpsgF-kEt8GzJI….
OAuthクライアントのID
OAuthのフローのタイプ：認可コードフロー
クライアントへのリダイレクトURL
要求するリソースのスコープ
state（セッション単位で使う乱数値）
クライアントへのリダイレクトＵＲＬ
認可コード

②アクセストークンのリクエスト
• リクエスト（POST)
• レスポンス（200)
15
https://認可サーバー/トークンエンドポイント
リクエスト・ボディ
grant_type=authorization_code
&code= AQIDBAWaII5T42Sle5s63NpsgF-kEt8GzJI….
グラント・タイプ（リクエストの方式指定）
先ほど取得した認可コード
アクセス・トークン
リソースオーナーが提示した認可コードを、クライアントがアクセストークンに引き換え
{
"access_token":"eyJ4NXQjUzI1NiI6IjdZalN6SVl3SnRb3oKpEH9h6iqjpptaNnLsEG......",
"token_type":"Bearer",
"expires_in":3600,
"refresh_token":"AQIDBAX6-uRDWMb3oKpEH9h6iqjpptaNnLsEG_Qr4-xB7wYQrf.....",
}
リフレッシュ・トークン
（オプション、scopeにoffline_access

アクセストークンの実体…
16
eyJ4NXQjUzI1NiI6IjdZalN6SVl3SnRzUVVoeHZ3UnYyT0dSV0hqR24wTFk2ZTJleTJ1MjZOUDQiLCJ4NXQiOiJLUUJSb2pZWTQ3
ZlN2THp1YWRPWkZqcFFzeVUiLCJraWQiOiJTSUdOSU5HX0tFWSIsImFsZyI6IlJTMjU2In0.eyJ1c2VyX3R6IjoiQXNpYVwvVG9re
W8iLCJzdWIiOiJtb3Rva2kuaXNha2FAb3JhY2xlLmNvbSIsInVzZXJfbG9jYWxlIjoiamEiLCJpZHBfbmFtZSI6ImxvY2FsSURQIiwidX
Nlci50ZW5hbnQubmFtZSI6ImlkY3MtYmFhNmQ0M2NmMTBkNGY5NzhiOWZhMmE3YjNhMTFkZmYiLCJpZHBfZ3VpZCI6ImxvY
2FsSURQIiwiYW1yIjpbIlVTRVJOQU1FX1BBU1NXT1JEIl0sImlzcyI6Imh0dHBzOlwvXC9pZGVudGl0eS5vcmFjbGVjbG91ZC5jb21
cLyIsInVzZXJfdGVuYW50bmFtZSI6ImlkY3MtYmFhNmQ0M2NmMTBkNGY5NzhiOWZhMmE3YjNhMTFkZmYiLCJjbGllbnRfaWQi
OiIwZDhhOTM1MGI1ZGQ0NzM3ODE5NzE0MGI1YjQ0OTc4NSIsInNpZCI6IjY4N2M5NDQzLTgxM2ItNDkzZS05NTY0LTRjYWJm
YjI3ZGU2YyIsInN1Yl90eXBlIjoidXNlciIsInNjb3BlIjoib3BlbmlkIHByb2ZpbGUgb2ZmbGluZV9hY2Nlc3MgZW1haWwiLCJjbGllbnRfd
GVuYW50bmFtZSI6ImlkY3MtYmFhNmQ0M2NmMTBkNGY5NzhiOWZhMmE3YjNhMTFkZmYiLCJ1c2VyX2xhbmciOiJqYSIsImV4
cCI6MTU1NTU3MzIxNCwiaWF0IjoxNTU1NTY5NjE0LCJjbGllbnRfZ3VpZCI6ImM4YTI2ZjAxNGJlYjQ5ZjBhY2U0MzJlNDMxMTNh
ODJkIiwiY2xpZW50X25hbWUiOiJpc2FrYV9DdXN0b21lclF1b3RlcyIsImlkcF90eXBlIjoiTE9DQUwiLCJ0ZW5hbnQiOiJpZGNzLWJh
YTZkNDNjZjEwZDRmOTc4YjlmYTJhN2IzYTExZGZmIiwianRpIjoiMzU2ZTc5NmEtOTM3NC00ZWE1LWIyMTktODkxODA3MGY3
MDYyIiwidXNlcl9kaXNwbGF5bmFtZSI6Ik1vdG9raSBJc2FrYSIsInN1Yl9tYXBwaW5nYXR0ciI6InVzZXJOYW1lIiwidG9rX3R5cGUi
OiJBVCIsImF1ZCI6Imh0dHBzOlwvXC9pZGNzLWJhYTZkNDNjZjEwZDRmOTc4YjlmYTJhN2IzYTExZGZmLmlkZW50aXR5Lm9y
YWNsZWNsb3VkLmNvbSIsInVzZXJfaWQiOiI1YjUwM2Y0NmM3MWI0MmJiOGViZjMzOTQxMjQzNjdjYiIsInRlbmFudF9pc3MiOiJ
odHRwczpcL1wvaWRjcy1iYWE2ZDQzY2YxMGQ0Zjk3OGI5ZmEyYTdiM2ExMWRmZi5pZGVudGl0eS5vcmFjbGVjbG91ZC5jb20i
fQ.F0uL7hDRy6ZFds-ACvAxaXNOz04iiOuSdZpefVU-i0wnFOYtty-Qplo66UMlwCoAPxBrA-
__KKPAbve9N5prl6qFOe7QlsJ74hi6wfw4OTIEU4hVL9HsMS8nbSk_oRThIWuDDQ3U1Zp0C8ra5oQNuiz_oxfw0Aw7W7_Wa5yO
WeQgxPDMcvhjsfDpO5eHU5NUZDclurNU_SplaPx60PC4TdozOFCfhnICZYHmn0Gnp5le04UOnVOvQtVaY9vUP4tnjLMaOOFGT
DbcC79W8STfGRKsAqgyk7bZIYoOC8TT1e-lFhffIavkpdvvnOaYioJcNtq4nKgpCSRd4Ei0GRy9vw
eyJ4NXQjUzI1NiI6IjdZalN6SVl3SnRzUVVoeHZ3UnYyT0dSV0hqR24wTFk2ZTJleTJ1MjZOUDQiLCJ4NXQiOiJLUUJSb2pZWTQ3
ZlN2THp1YWRPWkZqcFFzeVUiLCJraWQiOiJTSUdOSU5HX0tFWSIsImFsZyI6IlJTMjU2In0.eyJ1c2VyX3R6IjoiQXNpYVwvVG9re
W8iLCJzdWIiOiJtb3Rva2kuaXNha2FAb3JhY2xlLmNvbSIsInVzZXJfbG9jYWxlIjoiamEiLCJpZHBfbmFtZSI6ImxvY2FsSURQIiwidX
Nlci50ZW5hbnQubmFtZSI6ImlkY3MtYmFhNmQ0M2NmMTBkNGY5NzhiOWZhMmE3YjNhMTFkZmYiLCJpZHBfZ3VpZCI6ImxvY
2FsSURQIiwiYW1yIjpbIlVTRVJOQU1FX1BBU1NXT1JEIl0sImlzcyI6Imh0dHBzOlwvXC9pZGVudGl0eS5vcmFjbGVjbG91ZC5jb21
cLyIsInVzZXJfdGVuYW50bmFtZSI6ImlkY3MtYmFhNmQ0M2NmMTBkNGY5NzhiOWZhMmE3YjNhMTFkZmYiLCJjbGllbnRfaWQi
OiIwZDhhOTM1MGI1ZGQ0NzM3ODE5NzE0MGI1YjQ0OTc4NSIsInNpZCI6IjY4N2M5NDQzLTgxM2ItNDkzZS05NTY0LTRjYWJm
YjI3ZGU2YyIsInN1Yl90eXBlIjoidXNlciIsInNjb3BlIjoib3BlbmlkIHByb2ZpbGUgb2ZmbGluZV9hY2Nlc3MgZW1haWwiLCJjbGllbnRfd
GVuYW50bmFtZSI6ImlkY3MtYmFhNmQ0M2NmMTBkNGY5NzhiOWZhMmE3YjNhMTFkZmYiLCJ1c2VyX2xhbmciOiJqYSIsImV4
cCI6MTU1NTU3MzIxNCwiaWF0IjoxNTU1NTY5NjE0LCJjbGllbnRfZ3VpZCI6ImM4YTI2ZjAxNGJlYjQ5ZjBhY2U0MzJlNDMxMTNh
ODJkIiwiY2xpZW50X25hbWUiOiJpc2FrYV9DdXN0b21lclF1b3RlcyIsImlkcF90eXBlIjoiTE9DQUwiLCJ0ZW5hbnQiOiJpZGNzLWJh
YTZkNDNjZjEwZDRmOTc4YjlmYTJhN2IzYTExZGZmIiwianRpIjoiMzU2ZTc5NmEtOTM3NC00ZWE1LWIyMTktODkxODA3MGY3
MDYyIiwidXNlcl9kaXNwbGF5bmFtZSI6Ik1vdG9raSBJc2FrYSIsInN1Yl9tYXBwaW5nYXR0ciI6InVzZXJOYW1lIiwidG9rX3R5cGUi
OiJBVCIsImF1ZCI6Imh0dHBzOlwvXC9pZGNzLWJhYTZkNDNjZjEwZDRmOTc4YjlmYTJhN2IzYTExZGZmLmlkZW50aXR5Lm9y
YWNsZWNsb3VkLmNvbSIsInVzZXJfaWQiOiI1YjUwM2Y0NmM3MWI0MmJiOGViZjMzOTQxMjQzNjdjYiIsInRlbmFudF9pc3MiOiJ
odHRwczpcL1wvaWRjcy1iYWE2ZDQzY2YxMGQ0Zjk3OGI5ZmEyYTdiM2ExMWRmZi5pZGVudGl0eS5vcmFjbGVjbG91ZC5jb20i
fQ.F0uL7hDRy6ZFds-ACvAxaXNOz04iiOuSdZpefVU-i0wnFOYtty-Qplo66UMlwCoAPxBrA-
__KKPAbve9N5prl6qFOe7QlsJ74hi6wfw4OTIEU4hVL9HsMS8nbSk_oRThIWuDDQ3U1Zp0C8ra5oQNuiz_oxfw0Aw7W7_Wa5yO
WeQgxPDMcvhjsfDpO5eHU5NUZDclurNU_SplaPx60PC4TdozOFCfhnICZYHmn0Gnp5le04UOnVOvQtVaY9vUP4tnjLMaOOFGT
DbcC79W8STfGRKsAqgyk7bZIYoOC8TT1e-lFhffIavkpdvvnOaYioJcNtq4nKgpCSRd4Ei0GRy9vw

アクセストークンのフォーマット： JWT (JSON Web Token)
RFC 7519 https://tools.ietf.org/html/rfc7519
17
• パーティ間で情報を安全に送信するための、コンパクトで自己定義的な方
法を定義する標準
• JSONの形で、必要なデータを全て含む
• JWTの構造 Base64（ヘッダー）+ ”." + Base64（ペイロード）+ ”." +署名
Header
{
"alg": ”HS256”,
"typ": "JWT"
}
Payload
{
"sub": " taro.suzuki",
"iss": "https://identity.oraclecloud.com/",
"scope": "urn:opc:idm:t.security.client"
}
Signature
RSASHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret
)

アクセストークンの例(抜粋)
18
{
"user_tz": "Asia/Tokyo",
"sub": “taro.suzuki",
"idp_name": "localIDP",
"user.tenant.name": "idcs-1234",
"user_tenantname": "idcs-1234",
"exp": 1535366702,
"iat": 1535363102,
"client_guid": "0af724545f624c18b85…",
“client_name”: “Local Print Service",
"tenant": "idcs-1234",
"jti": "bc8479c9-17e9-4430-b9b0-1cf51185f567",
"user_displayname": “Taro Tanaka",
"sub_mappingattr": "userName",
"tok_type": "AT",
"aud": "https://photo.com/view",
"scope": "quote"
"user_id": "5b503f46c71b"
}
Taro.Suzukiさん（リソース・オーナー）が、 Local Print Service（クライアント）に、
https://photo.com/view（リソース）にアクセスを許可(認可）
Audience（誰に）
スコープ（何を許可）
リソースオーナー（誰が）
認可サーバー

アクセストークンの検証
• リソース・サーバーではクライアントが提示したアクセストークンの有効性を検証する必要がある。
19
方法１：リソースサーバー自身で検証
・署名検証
認可サーバーが発行したものか？
改ざんされていないか？
・自分自身宛か？
Audienceの確認
・有効期限
・アクセストークンの取り消しの検知が
できない。
方法２：認可サーバーの検証機能を利用
・イントロスペクション・エンドポイントを利用
アクセストークンを送付して検証実施
・実装が容易
・アクセストークンの取り消しの検知が可能
{
"active": true,
"client_id": "l238j323ds-23ij4",
"username": "jdoe",
“scope”: “view",
"sub": "Z5O3upPC88QrAjx00dis",
“aud”: “https://リソースサーバー/resource",
"iss": "https://server.example.com/",
"exp": 1419356238,
"iat": 1419350238,
"extension_field": "twenty-seven"
}
{
"active": false
}
有効時の応答例無効時の応答例

クライアントのタイプとOAuthのフロー
20
機密クライアント
クレデンシャルを
機密に扱えない
パブリック・クライアント
トークンの取得には、クライアントに認証が必要。
正しく認可コードをクライアントに渡せば、安全に
アクセストークンが扱われる。
安全にクレデンシャルを保持的ないため、クライアント
を検証（認証）できない。クライアントを認証しない
フローが用いられる。

パブリッククライアントの認可コードフロー例
21
システム
ブラウザ
認可サーバー
クライアント
認可コードフローを開始
認可リクエスト
認可コードを発行
リソース（写真一覧）
認可コードでトークンリクエスト
アクセストークン + リソース取得API（写真一覧）・アクセス
トークン検証
・認可判断
写真を取得
てきます。
・写真の参照
はいいいえ
ID
PWD

パブリッククライアントの注意点
• クライアントを認証できないため、認可コードを盗難されたら、容易にアクセストークン
を取得されてします。
• モバイルアプリ（OAuthクライアント）とシステム・ブラウザの間に、マルウェアが入り、
認可コードを盗難できるリスクがある。
• 対策（推奨）
– PKCE(Proof Key for Code Exchange by OAuth Public Clients、RFC 7636)
– クライアントはcode_challengeとよばれるチャレンジ・コードを発行し、code_challenge_methodと呼ば
れる暗号化方式名を送付。 code_challenge認可コードに紐づけることで、盗難時されてもアクセス
トークンを取得ができないようにする。
• ご参考
– Identity cloud service : Mobile clients and PKCE support
• http://www.ateam-oracle.com/identity-cloud-service-mobile-clients-and-pkce-support/
22

PKCEを用いた認可コードフローのシーケンス例
23
システム
ブラウザ
認可サーバー
クライアント
認可コードフローを開始
認可リクエスト
認可コードを発行
認可コード＋
アクセストークン + リソース取得API（写真一覧）
・アクセス
トークン検証
・認可判断
写真を取得
てきます。
・写真の参照
はいいいえ
ID
PWD
認可コード発行、
に紐つけ
code_challenge
code_challenge
_method
code_virifier
に紐づく認可コード
の確認

OAuthのフロー・タイプ
名称認可コード・
フロー
インプリシット
・フロー
リソース・オー
ナー・クレデン
シャル・フロー
クライアント・ク
レデンシャル・
フロー
アサーション・
フロー
デバイス・
コード・
フロー
クライアント認証が必
須か
× × × 〇 × ×
クライアントがユー
ザーのPWDを必要と
するか
× × 〇 × × ー
ブラウザ〇〇 × × × 〇
アクセストークンのコ
ンテキスト
ユーザーユーザーユーザークライアントアサーション
のサブジェクト
に依存
ー
リフレッシュ・トークン
の利用可否
〇 × 〇 × 〇〇
24

OAuth認証？
• 認可は認証が前提
– 認可サーバは、認可情報（アクセストークン）を発行する際に、まずユーザーの認証を行う。
– 簡単だから認証に使ってしまえ！（＝OAuth認証）
• アクセストークンの悪用のリスク
– Implicitフローでは、悪意のあるアプリがあっさりユーザーのアクセストークンを取得して、悪用が可能。
– アクセストークンは、Bearer型（持参人式）のトークン
• “誰のトークン“ではなく、持っていれば誰でもトークンが使えてしまう。
– 発行されたアクセストークンは、誰でも利用可能
• 成り済まし
25
OAuthの使い方を誤るとリソースサーバーの不正操作、情報の流出が発生
認証目的には、OpenID Connectを利用

OpenID Connectによる認証
26
(Webブラウザ)
認証・認可サーバークライアント
ログインボタンをクリック
認可リクエスト（リダイレクト）
認可コードを発行（リダイレクト）
IDトークン、アクセストークン
トークンリクエスト
+ ユーザー属性取得
IDトークン検証
ログイン状態を生成
/userinfo
必要に応じてより、
追加の取得属性
Sub（対象ユーザー）
Aud（宛先）
有効期限
署名
ログイン完了

OpenID Connect/Oauthと“認証”
• OpenID Connect、OAuthではユーザーそのものの認証方法は定めていな
い。
– 認可リクエスト後の認証画面は認可サーバー独自のもの
– 独自の認証方式を実装する
• ID/パスワード認証
• 各種2要素認証
• ソーシャルログイン
• FIDO2、など
• 認証した情報（IDトークン）をクライアントに提供し、クライアントはIDトーク
ンを検証することで、ユーザーを“認証”できる
27

①OpenID Connectの実施例
• OAuth / OpenID Connectの使い分け
– リクエストのパラメータで、 OAuthかOpenID Connectなのか決まる。
– scope = openidが必須。Profie、emailで追加情報が取得可能
28
• リクエスト（Get)
• レスポンス（303 See Other)
https://認可サーバー/認可エンドポイント
?client_id=2b0c89ed177d42858d48747f97f03b56
&response_type=code
&redirect_uri=https://クライアント/<return_uri>
&scope=openid
&nonce=b621b8e1-eeff-487c-9ef3-ab92a178a720
&state=ai2zjfie3!
クライアントのID
フローのタイプ
クライアントへのリダイレクトURL
要求するリソースのスコープ：openid
リプレイ攻撃対策（必須）
Location:
https://クライアント/<return_uri>
?code=AQIDBAWaII5T42Sle5s63NpsgF-kEt8GzJI….
クライアントへのリダイレクトＵＲＬ
認可コード
CSRF対策（オプション）

②IDトークン、アクセストークンのリクエスト
• リクエスト（POST)
• レスポンス（200)
29
https://認可サーバー/トークンエンドポイント
リクエスト・ボディ
grant_type=authorization_code
&code= AQIDBAWaII5T42Sle5s63NpsgF-kEt8GzJI….
グラント・タイプ（リクエストの方式指定）
先ほど取得した認可コード
アクセス・トークン
リソースオーナーが提示した認可コードを、クライアントがアクセストークン、IDトークンに引き換え
{
"access_token":"eyJ4NXQjUzI1NiI6IjdZalN6SVl3SnRb3oKpEH9h6iqjpptaNnLsEG......",
“token_type”:“Bearer”, "expires_in":3600,
"id_token":"eyJ4NXQjUzI1NiI6IjdZalN6SVl3SnRzUVVoeHZ
}
IDトークン

IDトークンの例
30
{
"sub": “Taro.Suzuki",
"user_locale": "en",
"idp_name": "localIDP",
"idp_guid": "localIDP",
"amr": [
"USERNAME_PASSWORD"
],
"user_tenantname": "idcs-1234",
"client_id": "2b0c89ed177d42858d48747f97f03b56",
"sid": "dcaffb07-165a-4b8b-9d94-4177cbe52ea9",
"authn_strength": "2",
"azp": "2b0c89ed177d42858d48747f97f03b56",
"auth_time": "1535362883",
"session_exp": 1535391683,
"user_lang": "en",
"exp": 1535391683,
"iat": 1535363102,
"idp_type": "LOCAL",
"tenant": "idcs-1234",
"jti": "29b1585b-fc76-410e-8166-728fbf2412a4",
"user_displayname": “Taro Suzuki",
"sub_mappingattr": "userName",
"tok_type": "IT",
"nonce": "1e1640da-e1c2-45c8-a656…",
"aud": [
"https://identity.oraclecloud.com/",
"2b0c89ed177d42858d48747f97f03b56"
],
"user_id": "5b503f46c71b42bb8ebf3394124367cb"
}
認証された
ユーザーID
宛先
クライアントID
リプレイ
アタック対策
IDトークンでは、aud（宛先）がクライアント
確かに自分(クライアント）向けに発行された認証情報だと分かる
（アクセストークンのaudはリソースサーバー）

まとめ
• OAuth
– 認可の仕組み
– アクセストークンのaudは、リソースサーバー
• OpenID Connect
– 認証・認可の仕組み
– アクセストークンのaudは、リソースサーバー
– IDトークンのaudは、クライアント
• 目的とクライアントのタイプで使い分ける。
31

Oracle Identity Cloud Service
クラウドネイティブで実装されたIDaaS (ID as a Service)
33
• ID管理
• アクセス管理
• 多要素認証
• プロビジョニング
• モバイル
オンプレミス
Active Directory Oracle Identity
Cloud Service
Oracle IDM
SFDC, Office365
Workday
Box など
シングルサイオン
多要素認証
開発柔軟性
• SMSを用いたワンタイムパスワードや、
iPhone、Android等のモバイルアプリを提供
• 一度認証した端末は、一定期間第2認証
のスキップが可能
• 標準対応（SAML、OAuth 2.0、OpenID Connect)
• 各サービスはIDCSに対して認証することで
シングルサインオンを実現
• オンプレミス環境も含めたハイブリッド環境の
シングルサインオンを実現
• 各種機能をAPIで提供
• ユーザーログイン画面、管理画面などを開発可能
SAML, OAuth2.0, OpenID Connect, SCIMなど
標準技術・標準規格を採用
カスタムアプリ
＠クラウド
＠オンプレミス

OCHaCafe#5 - 避けては通れない！認証・認可

OCHaCafe#5 - 避けては通れない！認証・認可

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to OCHaCafe#5 - 避けては通れない！認証・認可

Similar to OCHaCafe#5 - 避けては通れない！認証・認可 (20)

More from オラクルエンジニア通信

More from オラクルエンジニア通信 (20)

Recently uploaded

Recently uploaded (10)

OCHaCafe#5 - 避けては通れない！認証・認可