The Client is not
always right!
Michael Schwartz, CEO Gluu
ServerClient
Level setting
User Agent,
UA, BrowserClient,
Relying Party,
RP
Subject,
sub, User,
End User,
Person,
“Meat”
OpenID Provider,
Identity Provider,
Authorization Server,
OP, IDP, AS
Source: Nat Sakimura, CIS 2016
Supporting low to high assurance with OpenID
back channel token front channel token
public clientConfidential client
Basic Client Hygiene
No access tokens as query parameters
BAD, BAD, BAD, BAD!!!!(I know none of you would do this…)
Don’t forget about Form Post Response Mode: the fragment
shows up in the browser history
http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
Not all client creds are created equal
Method Secret Not
Sent in the
Clear
Signed Only
client has
secret
client_secret_basic
Client_secret_post
client_secret_jwt X X
private_key_jwt X X X
Cross Site Request
Forgery
1. Use non-static state
values to make sure the
response received at your
callback corresponds to a
request you actually
made. Verify either state
or s_hash in response.
CSRF: The Most Common OAuth 2 Vulnerability
http://www.twobotechnologies.com/blog/2014/02/importance-of-state-in-oauth2.html
2. iss - verify that the
token was issued by the
correct OpenID Provider
3. aud - verify this is
your client_id
4. nonce - verify it
matches the nonce value
you sent in your request.
5. exp - verify that the
assertion is not expired!
Minimal id_token claim validation
{
"iss": "https://idp.example.com",
"aud": "9bac-4ada-9c64",
"nonce": "1d58c9a9-cb05-4e7f",
"at_hash": "77QmUPjzWtFAnKRQ",
"exp": 1494702905,
"sub": "3046f517963f"
}
6. Verify the signature!
TLS is not perfect...
Symmetric - use your
client secret to verify
Asymmetric - use the
public key of the OP to
verify
signature
9. iat- Maybe you want
an id_token that was
issued with a certain
time frame?
10. auth_time - check
if too much time has
elapsed since the user
authenticated. If
necessary send the user
back for re-
authentication with the
prompt=login
authorization endpoint
parameter.
Optional id_token claim validation
{ "at_hash": "ae09d...897d91b",
"s_hash": "febb18...29802",
"iat": "1494702905",
"auth_time": "1494323431"
}
7. at_hash - verify that
you are using the correct
access token. Required
for implicit.
8. s_hash - in lieu of the
state param, verifies the
state without leaking it.
OpenID Connect Implementer’s Guides
Basic Client:
http://openid.net/specs/openid-connect-basic-1_0.html
Implicit Client
http://openid.net/specs/openid-connect-implicit-1_0.html
Advanced Client Hygiene
Hybrid Flow
“response_type”: “code id_token”
Returns id_token from authorization endpoint in addition to code
Adds c_hash, enables verification you got the right code.
Send code only to the token endpoint of the issuer to prevent IDP mix-up attack.
You can also request a token, but why?
Don’t ask for an access token unless you can answer that.
(And please come see me after and tell me your use case…)
Request Object or Request URI
Prevents attacker from tampering with your request parameters.
Examples of this attack are the Malicious Endpoint Attack and the IDP
Confusion Attack
Some OP’s may provide a Request URI endpoint, where the request can be
registered (enables state and nonce to be dynamic)
Distinct redirect_uri per OP
Check to make sure the response was received at the endpoint intended for this
issuer.
Cross reference with the state and nonce
Do you need to protect the id_token from the browser (hybrid flow)?
Will a JWT be passed to parties that you don’t want to see it?
id_token_encrypted_response_alg
id_token_encrypted_response_enc
userinfo_encrypted_response_alg
Userinfo_encrypted_response_enc
Do you want to protect the request from the browser?
request_object_encryption_alg
request_object_encryption_enc
Encryption
PKCE
Use for all public clients to prevent Authorization Code
Interception Attack
Require this if third parties use your OP from mobile apps
Use SHA 256 as the code challenge method
Mutual TLS
Protection for the token endpoint
TLS 1.2 or later as defined in RFC 5246 following best
practices from RFC 7525.
IETF Draft: “Mutual TLS Profiles for OAuth Clients”
https://tools.ietf.org/html/draft-campbell-oauth-mtls-01
Token Binding to TLS
TLS
Channel 1
TLS
Channel 2
OAuth 2.0 Token Binding: add SH256 hash of TLS Channel ID to id_token
Specifying ACR (authn context class reference)
acr_values param can be sent in the OpenID Connect authentication
request
default_acr_values can be registered for a client
Verify id_token for acceptable acr claim
RECOMMENDATION: Use FIDO U2F USB tokens to prevent MITM
attacks--authentication stops if the browser and server are not directly
connected!
Crypto guidelines
RSA keys with a minimum 2048 bits if using RSA cryptography;
Elliptic Curve keys with a minimum of 160 bits if using Elliptic Curve
cryptography
Client secret should have a minimum of 128 bits if using symmetric key
cryptography
Sign with PS256 (RSASSA-PSS using SHA-256 and MGF1 with SHA-256) or
ES256 (ECDSA using P-256 and SHA-256)
Trust: how do I know the public key is authentic?
OpenID Connect Federation Draft Spec:
http://openid.net/specs/openid-connect-federation-1_0.html
Client can download the signing_keys ahead of time, or obtain
them from a trusted source like a multi-party federation
(check out Kantara OTTO…)
Signature enables client to detect if jwks_uri is not authentic
Software statements
Restrict client registration...
“JWT that asserts metadata values about the client software as a bundle”
https://tools.ietf.org/html/rfc7591#section-2.3
Use OpenID Connect RP Metadata Statement as software statement
during registration?
Extra claims: scopes and claims
Signed by federation
OIDC Client Hall of Fame
Mod_auth_openidc
https://github.com/pingidentity/mod_auth_openidc
OIDC-Client-JS
https://github.com/IdentityModel/oidc-client-js
OXD (Middleware)
https://oxd.gluu.org
App Auth (iOS / Android)
https://github.com/openid
Bias Warning… This is Gluu’s client software.
THANK YOU!
Questions? [email protected]
Schedule a follow up: https://gluu.org/booking
Try OXD client software for free: https://oxd.gluu.org
Top Related