State Database

Purpose

As explained in the Services section, the services are linked together by ServiceContext, each service accumulating the information carried. The core services - Authentication, AccessToken, RefreshAccessToken and UserInfo - however require also State Database for storing request and response messages. The name of the database comes from the oauth2 state parameter as it is used as the key to access the database.

When running the core service in sequence, to authenticate the user and to fetch the user claims, the same instance of State Database needs to be shared by the services. See full conversation for an example how it is done. One example of sharing the State Database is UserInfo service picking access token automatically from Token Response. After running a successfull sequence you may pick the results directly from the State Database using the same state value.

IDToken iDToken=(IDToken)stateDb.getItem(state, MessageType.VERIFIED_IDTOKEN);
OpenIDSchema userInfo=stateDb.getItem(state, MessageType.USER_INFO); 

Items

Items stored to State Database per state are

• Authentication Request
• Authentication Response
• Token Response
• Refresh Request
• Refresh Response
• UserInfo Response
• ID Token

State implementation

The Service project implements a default in memory version of the State Database. If you have a need to replace it with something else, for instance to share the information using memcache, you may implement your own State Database. The required interface for the implementation is State