To use the IDP Kits functionality, we need a client and collect client_id and client_secret. Those credentials will be used by Keycloak to make requests to the IDP Kit, which will in turn ask the user if they want to sign in and check if they are allowed to do so, based on the NFTs they hold in their wallet. After collecting the consent of the user and validating that they are allowed to log in, the IDP Kit will give Keycloak a secret with which it can request information about the authenticated the user.
The exchange of information between the client, which is in our case Keycloak and the authorization server which is the IDP Kit are based on the OpenID Connect standards. I won't go into more detail here, but you can learn more about it in the concept section or watch this great illustrative video from OktaDev, which gives a great overview about OpenID Connect. To understand how the base ideas are then translated to the NFT use case, you can dive into Identity provision via NFTs
Now that we know what we need and why we need it, let's go ahead and create our first client. Depending on the situation and personal preference, there are two options available: CLI tool, API.
To register a new client, we can use the clients register command provided under the OIDC scope of the CLI tool.
Parameter description
-n - Name of the client
-r - The redirect URL which should be used in the OIDC flow
Other Options:
--all-redirect-uris - Redirect can go to any URL specified in the OIDC flow requests
If we set a redirect URL we can make sure that no other party will be able to use our authentication flow, even if they would get access to our secrets. For our project we set the URL http://localhost:8082/realms/NFT/broker/nft/endpoint as this is the location where Keycloak wants us to redirect the user to. Later if we were to put keycloak into production it would be something like https://{host}/realms/NFT/broker/nft/endpoint. In this case we would need to update our registerd client and reflect the new redirect URL.
To update an existing client, we can use the clients register command provided under the OIDC scope of the CLI tool and add the -u flag to note that we want to change a client with the specified id.
Parameter description
-n - Name of the client
-r - The redirect URL which should be used in the OIDC flow
-u - The ID of the client we would like to update
Learn more CLI tool commands and options.
In order to use the API, we need to launch it first.
To register a new client, we can make a POST request to /api/oidc/clients/register. However, by default the registration of new clients via API, requires you to authenticate. Providing the master_token in the header of the request makes sure the registration goes through.
To get the master_token we can execute the clients token command under the OIDC scope of the CLI tool.
We need to replace master_token in the Authorization request header before executing.
Save the response somewhere, where you can later retrieve the information. Most importantly, the client_id and client_secret.
If we set a redirect URL we can make sure that no other party will be able to use our authentication flow, even if they would get access to our secrets. For our project we set the URL http://localhost:3000 as this will be the URL under which our frontend application will be hosed. Later if we were to put the application into production it would be something like https://applicationName.com. In this case we would need to update our registerd client and reflect the new redirect URL.
To update a client we make a PUT request to the /api/oidc/clients/<client_id> and provide the registration_access_token, which we got during client registration. In order for the update to go through, we need to provide the whole response we got from the client registration step in the update request body.
Make sure before executing the request, to replace the clientid in the request URL and the registration_access_token
Learn more API endpoints and options or visit the swagger docs.