This guide details how to hook up an internally managed identity provider to Authress to enable consistent token generation. In the case you want to connect a public federated provider instead, follow one of these guides:
An internally managed identity provider usually exists in a legacy platform. You have some architecture today to verify users and generate user identity tokens. If these tokens are already OIDC compliant and are signed by an asymmetric algorithm, then you should follow the Connecting a non-standard public identity provider guide.
This avoids the need for your applications to interoperate between two types of tokens–the ones that Authress generates, and the ones being generated by your legacy identity provider.
The standard Authress login flow, starts in your web app. The user requests to login, which generates a login request using one of your configured Authress connections. The connectionId and applicationId are passed to the login SDK. This is the same flow your application is already using to login with Authress, and it will be reused for your legacy identity provider, so no changes are necessary to your web app. As a reminder these are the relevant SDK methods:
To link the identity provider to Authress, a new special kind of connection will be created. This connection treats your existing identity provider with advanced permissions allowing it to request Authress identity tokens.
Generate a new Authress Service Client. Enter a name for the client, and select the option to
Grant the client OAuth user impersonation. This allows this client to directly communicate with the Authress login API to request user identity tokens.
Your identity provider has a UI associated with identifying the user. This may be a username/password prompt or an email prompt requesting the user’s email for a magic login token based flow. Set the
Authorization Url to be this URL.
At this point, it is recommended that you click
Test Connection to ensure that the redirect to your identity provider is correct.
When the user client logs in and the Authress Login SDK is invoked via the
loginClient.authenticate() method, the user will be redirected to the specific URL from #2 above. They’ll being the flow, whatever this may be. In the case of username/password or a magic token, you’ll use the existing logic to direct and navigate the user to the appropriate location. The result of their interactions must be a request to your existing identity service:
Important: Authress will send a
state parameter to your
Authorization URL. This state parameter must be passed back to Authress in the next step. This token is not sensitive and should not be treated as a replacement for a secure identity.
Once the user’s identity has been verified, the identity service is ready to hand-off the user to Authress to complete the login flow. This can be done using the
generateUserLoginUrl() method from one of the Authress SDKs, which creates the Authress assertion and redirect url. (Note: this happens inside the identity service, not in the user’s UI)
Step #4 generates an assertion in the form of a URL. This URL should be sent back to your user, in the form of a browser redirect. The user will be directed to Authress to complete the assertion, and then will be logged in with an Authress identity token. The token and user will be sent back to the origin application url that started the process.
Didn't find what you were looking for?
Or send us an email at firstname.lastname@example.org