Connect2id server 3.5
The long-awaited 3.5 release of the Connect2id server is here, with support for JWT bearer grants and secure client authentication based on RSA or EC signed JWT assertions.
JWT bearer assertion grants
The OAuth 2.0 spec defines various grants, or credential types, to obtain tokens for various applications or scenarios.
The JWT bearer grant is one such credential, designed to facilitate a client authorised in one domain to obtain tokens in another.
For example, a SaaS provider using the Connect2id server for OpenID Connect SSO and API management wants to allow enterprise customers to log in their users and determine their permissions internally. Once the user is authenticated, with MS-AD / LDAP or some other technology deployed at the enterprise, the user’s identity and permissions are packaged in a signed JWT assertion. The client app can then exchange this JWT for an access and / or ID token for the SaaS domain, by making a request to the Connect2id server.
The Connect2id server allows enterprises to apply arbitrary authorisation and business logic when processing JWT assertion grants, in order to determine the properties of the issued tokens (scope, audience, expiration, etc).
Key features:
-
Support for third-party issued (Secure Token Service) or self-issued (by the client itself) JWT grants.
-
The JWT assertions can be secured by means of HMAC or signature (RSA or EC).
-
Clients may authenticate implicitly via the JWT assertion itself.
-
It is possible to map
client_id
s between the two domains.
You can find more information in the JWT bearer manual. The JWT bearer grant is specified in RFC 7523.
Private key JWT authentication
Clients can now authenticate with JWT assertions. These are signed using an RSA or EC key pair generated by the client.
Private key JWT authentication has significant security benefits for client apps:
-
Basic authentication has a number of risks, the most significant of which is leaking the secret by mistake, for example by forgetting to use HTTPS or making a token request to an unintended or malicious endpoint. Private key JWT authentication is based on RSA or EC signed assertions, and even if they get leaked out the key to create them will not be compromised.
-
Clients can rotate the authentication keys as often as required by their security policy.
-
One fewer secret to worry about.
So, please, do use private key authentication. What’s required for that?
- Generate an RSA or EC key pair for your client app.
- Export the public key to a JWK set.
-
Register
the client’s JWK set with the Connect2id server, specifying
private_key_jwt
as the preferred authentication method.
Private key JWT authentication is specified in OpenID Connect, section 9 and RFC 7523.
Download
To download a ZIP package of Connect2id server 3.4:
https://c2id-downloads.s3.eu-central-1.amazonaws.com/server/3.5/Connect2id-server.zip
As WAR package only:
https://c2id-downloads.s3.eu-central-1.amazonaws.com/server/3.5/c2id.war
Questions?
Please contact Connect2id support.
Connect2id Server 3.5 release notes
Configuration
-
/WEB-INF/oidcProvider.properties
-
Adds support for private_jwt_key client authentication at the token endpoint, see op.token.authMethods property.
-
Adds support for the following standard JWS algorithms for private_jwt_key client authentication at the token endpoint, see op.token.authJWSAlgs property: RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384, ES512
-
-
/WEB-INF/selfIssuedJWTBearerHandler.properties
- New configuration file for the new optional OAuth 2.0 grant handler SPI for self-issued (client-issued) JWT bearer assertions (RFC 7523).
Web API
-
Client registration endpoint:
-
Supports registration of the standard “jwks” (JSON Web Key - JWK set) client metadata parameter for client public RSA and EC keys, for the purpose of private_key_jwt client authentication.
-
Initial registration access tokens can have the registration endpoint URI as an audience in addition to the OP issuer (issue server/167).
-
Returns HTTP 404 status code on a client read request with the master (admin) access token if the client_id is invalid to allow privileged clients and administrators to distinguish between an invalid access token and an invalid client_id (issue server/154). Client read requests using a regular registration access token will still produce a HTTP 401 Unauthorized on an invalid client_id.
-
Bug fixes
-
The audience (aud) JWT claim in client_secret_jwt client authentication at the token endpoint must match the token endpoint URI or the OP issuer identifier (issue server/157).
-
Fixes outgoing Infinispan marshalling of subject sessions with a “claims” field (issue session-store/25).
Dependencies
-
Adds com.nimbusds:oauth-jwt-self-issued-grant-handler:1.0.1
-
Upgrades to com.nimbusds:oauth2-authz-store:3.1.3
-
Upgrades to com.nimbusds:oidc-session-store:3.2
-
Upgrades to com.nimbusds:common:1.96
-
Upgrades to com.nimbusds:c2id-server-sdk:3.6
-
Upgrades to com.nimbusds:oauth2-oidc-sdk:5.0-alpha11
-
Upgrades to com.nimbusds:nimbus-jose-jwt:4.3.1
-
Upgrades to org.bouncycastle:bcprov-jdk15on:1.53
-
Upgrades to org.infinispan:infinispan-embedded:7.2.5.Final
-
Upgrades to org.glassfish.jersey.containers:jersey-container-servlet:2.22.1
-
Upgrades to org.apache.logging.log4j:log4j-web:2.4.1
-
Upgrades to org.apache.logging.log4j:log4j-slf4j-impl:2.4.1
Other
-
Adds Service Provider Interface (SPI) for handling OAuth 2.0 JWT bearer grants issued by the client (self-issued) (RFC 7523).
-
Includes a default handler for self-issued JWT bearer grants, see com.nimbusds:oauth-jwt-self-issued-grant-handler:1.0.1 package.
-
Adds Service Provider Interface (SPI) for handling OAuth 2.0 JWT bearer grants issued by a third party (secure token service) (RFC 7523).
-
Loads BouncyCastle JCA provider if advertised OP JOSE algorithms or access token JOSE algorithms are not supported by the default system JCA provider(s) (issue server/160).
-
Provides helpful error_description message on failed client authentication; exact error cause is not revealed.