Nexus Authentication can be used as a system-to-system service where the customer defines it's own users and roles.
Authentication in the customer's digital platform
Different systems in the customer's platform such as system adapters and client facades authenticate themselves using JWTs created by the Authentication service in Nexus Link Fundamentals.
The customer's Business api provides endpoints for creating tokens (based on ClientName and ClientSecret), and for getting the public key of the authentication, with wich a service can verify the signature of a JWT (the public key can be cached for a long time).
XLENT Link AB provides an SDK to make this easy.
Authentication
The operations below requires either Organization Admin access or Tenant Admin access.
- When prompted, enter the Organization Name or Environment Name as "Username" and the password, either for the organization or the tenant.
- See Authentication under Bootstrapping a new tenant
Create/Update/Delete authentication roles
To handle a basic level of authorization, use a set of authentication Roles of which a Client have one or more. These will be used as role claims in the token.
- Create an Authentication Role PRDSIM, [PRD](https://nexus-prd-fundamentals.azurewebsites.net/swagger/ui/index#!/Authentication32as32a32service/AuthenticationAdministration_CreateRoleAsync
- Delete an Authentication Role PRDSIM, PRD
Create/Read/Update/Delete Clients
For each client, create a Client with a set of Roles.
Use a token
- In the client, use the credentials to create a token through the customer's Business API
- The api in turn calls Nexus Fundamentals on PRDSIM, PRD
Validate a token
To validate a JWT, you need the public part of the key that was used to create it.
- Nexus Fundamentals provides an endpoint for getting the public key for a tenant.
- Use standard libraries to verify the signature of the token
- Or use the SDK provided by XLENT Link AB: Nexus.Link.Authentication.Sdk on nuget source http://fulcrum-nuget.azurewebsites.net/nuget