Connect2id server 7.7


We have another update of the Connect2id server for you, which is recommended if you have a deployment with an AWS DynamoDB backend, or intend to use the new feature introduced in version 7.6 for steering implicitly consented OpenID claims into the ID token, instead of returning them at the standard location for all code-based flows, the UserInfo endpoint.

For more information check the release notes below.


To download a ZIP package of Connect2id server 7.7:

SHA-256: e6b2e33de5b6701eb5224f8ad203e6917306a90825bdeb19df06b9d724f3956d

As WAR package only:

SHA-256: 813fe50a7bf927539d25db527b7312c6fd36a868b3c4e6119c680a495ac93381


Get in touch with Connect2id support.

Release notes

7.7 (2018-10-02)


  • Recommended update for Connect2id server deployments utilising a DynamoDB backend. Sanitises DynamoDB items before a database write to prevent DynamoDB ValidationExceptions when the optional data in client registrations, authorisation objects and other persisted objects contains empty strings or sets. Also adds new a configuration option for creating the DynamoDB tables with selected omitted global secondary indices (GSI) to conserve read and write capacity.

  • Recommended update for Connect2id server deployments utilising the "id_token:" prefix introduced in v7.6 to steer selected implicitly consented OpenID claims for delivery with the ID token instead of the UserInfo endpoint. Fixes a bug which included the prefix in persisted consent.


  • /WEB-INF/infinispan-*-dynamodb.xml

    • The global secondary indices (GSI) for the subject (sub), actor (act) and / or client ID (cid) attributes in persisted authorisation (consent) records can be selectively turned off by overriding the default "sub, act, cid" setting with a "dynamodb.authzStore.longLivedAuthzMap.indexedAttributes" Java system property. For example, "sub, act" will cause the creation of GSIs for the subjects and actors only, for client IDs related queries the Connect2id server will fall back to a DynamoDB scan request with a filter expression.

Resolved issues

  • Sanitises DynamoDB items before writing them to the table. Empty strings, empty binary data and empty sets, including those in nested JSON objects (maps), are automatically removed to fit the DynamoDB data model and prevent ValidationExceptions (issue authz-store/154).

  • OAuth 2.0 authorisation requests and OpenID authentication requests with an unsupported PKCE method (RFC 7636) are rejected with an "invalid_request" error and descriptive message, as required in section 4.4.1 of RFC 7636. Previously the Connect2id server would return an HTTP 500 status at the token endpoint if the PKCE method is not supported (other than "plain" and "S256") (issue server/401).

  • Implicitly consented claims with an "id_token:" prefix to trigger release via the ID token instead of at the UserInfo endpoint must be saved without the prefix in persisted authorisation records ("cls") (issue server/399).

Dependency changes

  • Updates to com.nimbusds:infinispan-cachestore-common:2.1

  • Updates to com.nimbusds:infinispan-cachestore-dynamodb:2.5

Connect2id server 7.6 with more options for OpenID claims delivery


September commences with a new release of the Connect2id server for enterprise OpenID Connect and OAuth 2.0, with useful updates in consent, global DynamoDB support and the SAML 2.0 grant handler.

Returning non-requested OpenID claims in the ID token

The Connect2id server can supply the relying party (RP) with OpenID claims (attributes) about the end-user that were not asked for in the authentication request.

When a non-requested OpenID claim is consented, it will get delivered according to the response_type parameter of the OpenID authentication request. For all response types other than response_type=id_token, this means the claim will be made available at the UserInfo endpoint.

To enable non-requested OpenID claims to be steered into the ID token instead, we made a small update to the authorisation session web API. Simply prefix the claim name with id_token: and this will make it appear in the ID token instead of at the UserInfo endpoint.

Here is an example The OpenID request with scope openid and email, which means the RP is requesting an ID token for the end-user as well as access to their email and email_verified claims:

The RP has initiated a code flow (response_type=code), so the default delivery method for any consented claims will be the UserInfo endpoint. If the IdP decides to additionally release the name claim, that claim will also appear in the UserInfo. To steer the name claim into the ID token, prefix it with id_token: when submitting the consent to the Connect2id server:

  "scope"  : [ "openid", "email" ],
  "claims" : [ "email", "email_verified", "id_token:name" ]

You can also make the name claim appear in both ID token and UserInfo:

  "scope"  : [ "openid", "email" ],
  "claims" : [ "email", "email_verified", "name", "id_token:name" ]

Global DynamoDB tables

If you intend to deploy the Connect2id server in the AWS cloud and persist its data to global DynamoDB tables, for seamless distributed operation across two or more AWS regions, the server can now automatically initialise the tables with the needed streams.

Check out our new guide for setting up the Connect2id server with global DynamoDB tables.

Updated SAML 2.0 grant handler

The SAML 2.0 assertion grant handler was updated from OpenSAML 2.x, which reached its end of life in 2016, to OpenSAML 3.x.

If you implemented a handler for exchanging SAML 2.0 assertions for OAuth 2.0 access tokens, update your code to OpenSAML 3.2 or later. The package names in OpenSAML 3.0 have changed, also the APIs of a few classes, but other than that your your overall handler design and code should not be affected.

The OpenSAML 3 guide by Stefan Rasmusson can help you.


To download a ZIP package of Connect2id server 7.6:

SHA-256: e6b2e33de5b6701eb5224f8ad203e6917306a90825bdeb19df06b9d724f3956d

As WAR package only:

SHA-256: 813fe50a7bf927539d25db527b7312c6fd36a868b3c4e6119c680a495ac93381


Get in touch with Connect2id support.

Release notes

7.6 (2018-09-08)


  • Updates the authorisation session web API to enable non-requested OpenID claims to be delivered in the ID token instead of at the UserInfo endpoint (for response types other than id_token).

  • Connect2id server deployments with an AWS DynamoDB backend database can now create the required tables with enabled streaming for replicating table data between two or more AWS regions.

  • Updates the SAML 2.0 grant handler SPIs to OpenSAML 3.x (breaking change).


  • /WEB-INF/infinispan-*-dynamodb.xml

    • Adds an optional boolean "enable-stream" configuration XML attribute to create the DynamoDB table with an enabled stream of view type NEW_AND_OLD_IMAGES. Streaming is required to setup the Connect2id server with global DynamoDB tables with replicas in two or more AWS regions. The setting is also exposed via the Java system property "dynamodb.enableStream" (defaults to "false", set to "true" to enable).


  • /authz-sessions/rest/v3/

    • Updates handling of consent in the authorisation session API. Consented OpenID claims that are not requested by the relying party can be marked for delivery in the ID token instead of at the UserInfo endpoint by prefixing their name with "id_token:" in the submitted consent to the Connect2id server. For example "id_token:email" will cause an implicitly consented "email" claim to be fed into the ID token. A non-requested claim can be delivered by both methods by including it twice, with the "id_token:" prefix an without, for example "id_token:email" and "email". Normally, all non-requested OpenID claims are delivered at the UserInfo endpoint, save for when the relying party requests only an ID token to be issued (with response_type=id_token).


  • com.nimbusds.openid.connect.provider.spi.grants.SelfIssuedSAML2GrantHandler

    • Updates the SAML 2.0 grant handler from OpenSAML 2.x to OpenSAML 3.x. Due to breaking changes in the OpenSAML 3.x API handler existing implementations need to be updated.
  • com.nimbusds.openid.connect.provider.spi.grants.ThirdPartySAML2GrantHandler

    • Updates the SAML 2.0 grant handler from OpenSAML 2.x to OpenSAML 3.x. Due to breaking changes in the OpenSAML 3.x API handler existing implementations need to be updated.

Dependency changes

  • Updates to com.nimbusds:c2id-server-sdk:4.0

  • Updates to com.nimbusds:oauth2-oidc-sdk:6.0

  • Updates to com.nimbusds:nimbus-jose-jwt:6.0.2

  • Updates to OpenSAML 3.2 (breaking change)

  • Updates to com.zaxxer:HikariCP:3.2.0

  • Updates to com.nimbusds:infinispan-cachestore-dynamodb:2.2

How to create a global DynamoDB table in AWS


In November 2017 AWS announced a DynamoDB feature enabling transparent asynchronous replication of table data between any number of regions. This can be useful in a distributed application and for failover between AWS regions. Data can be written and read in each of the regions with replicas of the table.

This is the missing guide for creating global tables with the AWS Java SDK. You'll need a recent version of the SDK as older releases lack the classes for dealing with global DynamoDB tables.

The steps for creating a global DynamoDB table:

  1. Create a DynamoDB client for each of the AWS regions where you need to have replicas.

  2. In each region create the desired DynamoDB table, with the usual parameters, but also enable the table for streaming and specify what is to be streamed - both the new and old images of the item (StreamViewType.NEW_AND_OLD_IMAGES).

  3. Finally, run a request to turn all those created tables into a single global one, by putting them into a replication group. This request can run in any AWS region.

Here is a Java example:

import java.util.Collection;
import java.util.LinkedList;

import com.amazonaws.auth.DefaultAWSCredentialsProviderChain;
import org.junit.Test;

public class AWSGlobalTableTest {

    private static final String EU_CENTRAL_1 = "eu-central-1";

    private static final String US_EAST_1 = "us-east-1";

    private static final String TABLE_NAME = "my_global_table";

    public void createGlobalTable() {

        // Create a client for each of the regions with table replicas
        AmazonDynamoDB client1 = AmazonDynamoDBClientBuilder

        AmazonDynamoDB client2 = AmazonDynamoDBClientBuilder

        // The table spec, must be enabled for streaming
        Collection<KeySchemaElement> keyAttrs = new LinkedList<>();
        keyAttrs.add(new KeySchemaElement("id", KeyType.HASH));

        Collection<AttributeDefinition> attrs = new LinkedList<>();
        attrs.add(new AttributeDefinition("id", ScalarAttributeType.S));

        CreateTableRequest createTableRequest = new CreateTableRequest()
                new StreamSpecification()
            .withProvisionedThroughput(new ProvisionedThroughput(1L, 1L));

        // Create the table in each region

        // The global table request can be executed in any of the regions
        CreateGlobalTableResult createGlobalTableResult = client1.createGlobalTable(
            new CreateGlobalTableRequest()
                    new Replica().withRegionName(EU_CENTRAL_1),
                    new Replica().withRegionName(US_EAST_1)));

Global tables will be automatically provisioned with three extra attributes - the timestamp of the item update, in which region that happened and a flag whether the item is pending deletion.

The Connect2id server for IdP, SSO and API security is going to support global DynamoDB tables in the next 7.6 release. This will make it possible to run a global IdP operation, with the ability to service clients and applications close to their deployment location for minimal latency.