Confirmation flow for Mytoken subtokens creation

[Nithe14]

When requesting a subtoken using a Mytoken profile, the user must confirm the creation of a new Mytoken via the GUI. Would it be possible to display a short-lived URL or QR code that the user can use to confirm the creation? This would be similar to the OAuth2 device flow concept.

Currently, when using oidc-agent on the remote node, the user is forced to forward X11 via SSH to confirm Mytoken creation. It would be great to handle this confirmation similarly to the profile creation process with the oidc-gen --flow=device command.

Currently, I am obtaining a new subtoken by running:

oidc-token --mytoken=<mytoken-profile> <account-name>

The agent-forwarding approach can handle this as well, but in my case, the end user is not expected to be familiar with oidc-agent. Account creation and token obtaining are mostly automated, so the user should only need to read messages, set the account password, and confirm the subtoken creation from the remote host where the agent is running.

I’m not sure if this is already supported, so I’m asking here in the Q&A section.

[zachmann]

This is currently not supported. The use-case seems reasonable. I agree that this would be nice to have.

First thought was yes that's trivial to support. However, actually it isn't. The requirement for a subtoken creation to be confirmed comes from oidc-agent not from mytoken, so this is implemented on the oidc-agent side. The prompting renders an html side (which includes content from mytoken) and the buttons are changed / added so that the prompt command does return the decision.

For a url to be printed to the user that is usable from another device the following would be required:

• The side content must be hosted somewhere reachable via the internet
  • this is not the case for the oidc-agent, so cannot be hosted by oidc-agent via localhost
  • could be hosted by mytoken
  • or another (third-party)
• The response must come back to the oidc-agent. There is no synchronous connection. So the agent would need to poll similar to the device flow and "native" mytoken consent polling.
  • IMO the most critical part the server must also support / implementing this polling.

So to support this this would require implementation work on both oidc-agent an mytoken.

[Nithe14]

Thank you for your response. I wasn’t aware it worked this way. I had assumed the confirmation content was hosted directly on the Mytoken server. For now, using X forwarding is a good workaround, but it might be worth considering in the future. Thanks!