What is the intention of the "my client" generation?
I can see that the consumers of the API endpoints that require authentication will need to generate an access token however we shouldn't need to create a new cognito app client for each user. The app client is intended for client application integration with the authentication provider ie. for a user who is building a client app that requires authentication to consume our services.
If that is the intention then we would need to collect more information prior to generating the client:
callback URL(s)
scopes
Currently these values are set using the application config oauth.support.dynamic.client and are therefore the same for each user requesting a "client ID", which seems to defeat the purpose of creating user specific ID.
If we do intend for true client app integration then there should be a application and vetting process before granting a client ID, and it should be for a specific (callback) URL with only the minimum required scopes.
If the intention is to allow users to generate an access token then we could provide a static client ID with a fixed set of available scopes we have defined for that purpose and provide the https://tokens-cognito-support.dev.ala.org.au tool to generate access tokens, or the user can make the calls via postman using the relevant static config. This process could provide longer lived access tokens or refresh tokens so the user could use these when consuming the apis.
Alternately a device authentication flow could be implemented to remove the inline user authentication from services that need to generate access tokens.
What is the intention of the "my client" generation?
I can see that the consumers of the API endpoints that require authentication will need to generate an access token however we shouldn't need to create a new cognito app client for each user. The app client is intended for client application integration with the authentication provider ie. for a user who is building a client app that requires authentication to consume our services.
If that is the intention then we would need to collect more information prior to generating the client:
Currently these values are set using the application config
oauth.support.dynamic.clientand are therefore the same for each user requesting a "client ID", which seems to defeat the purpose of creating user specific ID.If we do intend for true client app integration then there should be a application and vetting process before granting a client ID, and it should be for a specific (callback) URL with only the minimum required scopes.
If the intention is to allow users to generate an access token then we could provide a static client ID with a fixed set of available scopes we have defined for that purpose and provide the https://tokens-cognito-support.dev.ala.org.au tool to generate access tokens, or the user can make the calls via postman using the relevant static config. This process could provide longer lived access tokens or refresh tokens so the user could use these when consuming the apis.
Alternately a device authentication flow could be implemented to remove the inline user authentication from services that need to generate access tokens.