The OpenID Connect or OAuth frameworks can be used to achieve a range of security levels. Properly used, it mitigates many risks. However, OpenID Connect’s flexibility, combined with its shared ontogeny with OAuth 2.0, creates opportunities for error--developers may not use (or even know about ) certain features necessary to achieve the transaction integrity they desire. The good news is that client software and middleware services can do some of the heavy lifting. You can have the best of both worlds--maximizing security and developer joy. Whether you’re a developer or security architect, what should you look for in an application that acts as an OpenID Connect client?
8. 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
9. 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
10. 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
11. 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"
}
12. 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
13. 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.
16. 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…)
17. 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)
18. 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
19. 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
20. 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
21. 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
22. 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
23. 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!
24. 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)
25. 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
26. 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
27. 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.
As many of you know, the Gluu Server is an OpenID Connect Provider. The nature of our business is that Gluu writes the server, and our customers write the Clients. One of the challenges we face (and worry about…), is that we can write a really good server, but if you don’t write the client correctly, what you get is not secure.
Our industry has been really excellent at making up lots of jargon for roughly equivalent things… in this talk, I’m going to try to stick with User, Browser, Client and OP.
This is an excellent diagram presented by Nat Sakimura at CIS last year. I don’t want to get you bogged down in the technical stuff (yet)... but what I want you to focus on is the fact that using OpenID Connect you can achieve different security levels. OpenID Connect was designed to make “Simple things Simple; Complex things Possible.” Depending on the transaction value, you can use OpenID Connect to mitigate varying levels of risk during authentication.
Note: Implicit flow ain’t got not client creds… by definition a public client can’t protect them. So when you think back to the “Security Levels”... of course a confidential client is more secure.
Note: private key client authentication doesn’t send the secret. Most commercial agents are doing the same for years.
The main point is to send a state param, and check to verify it in the response. For more details, see Twobo’s blog.
An id_token is very much like a SAML assertion. Instead of a signed XML, it’s a signed JSON. SAML assertions also contain the issuer, audience, subject, expiration and optionally, user claims.
An id_token is very much like a SAML assertion. Instead of a signed XML, it’s a signed JSON. SAML assertions also contain the issuer, audience, subject, expiration and optionally, user claims.
These are the clients that I recommend to developers