Beruflich Dokumente
Kultur Dokumente
COM
OAUTH WITH
PINGFEDERATE
Ping Identity Education
2
GENERAL FLOW
IDTel’s
Authorization
1. Client redirects user to the 1. Client ID
+ scope
Server
authorization server AuthZ
(Tunes Partner website to ID requested Endpoint
Tel’s PingFederate).
Token
2. User Endpoint
2. User authenticates, then
authorizes the request. Authorization
(Yes, Tunes Partner can charge
me $10)
3.
Authorization 4. Auth Code + client secret
3. PingFederate redirects user Code in sent to PF
back to web app with an redirect 5. Access token (/refresh
authorization code token) sent to client
§ Maintain scope
list
§ Maintain client
list
§ Issue
authorization
codes
§ Issue access and
refresh tokens
§ Possibly,
authenticate user
Copyright © 2015 Ping Identity Corp. All rights reserved.4
SCOPES ARE DEFINED BY AUTHORIZATION
SERVER
§ A client app cannot request something not on the list
§ Can request any combination of the list
§ Idea:
– Short-lived tokens between the client and the RS
– Long-lived tokens between the client and the AS
§ Refresh an expired access token without involving user authorization
§ Refresh tokens can be revoked; access tokens can’t
Copyright © 2015 Ping Identity Corp. All rights reserved. 7
GENERAL CLIENT CONFIGURATION
§ A client will
initially send a
request
– “I’m TunesPartner
and want to
charge $5”
§ PingFederate will
check its client
list
Copyright © 2015 Ping Identity Corp. All rights reserved.8
GENERAL CLIENT CONFIGURATION
§ Client ID
§ Client secret
§ Redirect URI:
– Callback URL
§ Grant type
§ Client secret:
– optional
§ Refresh token:
– allowed
§ Redirect URI:
– yes
§ Client secret:
– no
§ Refresh token:
– no
§ Redirect URI:
– yes
§ Client secret:
– yes
§ Refresh token:
– allowed
§ Redirect URI:
– no
› (no browser!)
§ Client secret:
– yes
§ Refresh token:
– no
§ Redirect URI:
– no
› (no browser!)
15
ACCESS TOKEN VALIDATION GRANT CLIENT
① OAuth client
AuthZ
Endpoin application sends
t
the access token to
Token Resource Server
Endpoint
② RS validates
2. Access
Token incoming access
Validation token with
PingFederate
1. Access Token
§ Client secret:
– yes
§ Refresh token:
– no
§ Redirect URI:
– no
› (no browser!)
§ Client Endpoint
– Redirection URI
› Front channel callback for resource owner (browser redirect)
eserved.21
MANAGING GRANTS
22
PINGFEDERATE – PERSISTENT GRANTS TABLE
§ Single table
(pingfederate_access_grant):
Column Type
guid VARCHAR(32)
hashed_refresh_token VARCHAR(256)
unique_user_id VARCHAR(256)
scope VARCHAR(1024)
client_id VARCHAR(256)
grant_type VARCHAR(128)
context_qualifier VARCHAR(64)
issued TIMESTAMP
updated TIMESTAMP
expires TIMESTAMP
Copyright © 2015 Ping Identity Corp. All rights reserved. 23
USER MANAGEMENT OF PERSISTENT
GRANTS IN PINGFEDERATE
• https://<pfhost:port>/as/oauth_access_grants.ping
• Template:
<pf-home>/pingfederate/server/default/conf/template/oauth.access.grants.page.template.html
– By Clients
– By Users
/pf-ws/rest
– GET https://<pf-server:pf-runtime-port>/pf-ws/rest/oauth/clients/<clientID>/grants
– GET https://<pf-server:pf-runtime-port>/pf-ws/rest/oauth/users/<userID>/grants
– DELETE https://<pf-server:pf-runtime-port>/pf-ws/rest/oauth/users/<userID>/grants/<grantID>
eserved.27
OAUTH – ADAPTERS
§ IDTel authorization server needs to authenticate the
user
– whose bank account is being charged?
– USER_KEY
› An identifier for the user in general
✓
Issue Validate
Token Token
App API
✓
eserved.32
OAUTH ACCESS TOKEN MAPPING TO
CLIENT