Skip to content

Add scope on reauthenticate - #664

Closed
marcvs wants to merge 2 commits into
prerelfrom
add-scope-on-reauthenticate
Closed

Add scope on reauthenticate#664
marcvs wants to merge 2 commits into
prerelfrom
add-scope-on-reauthenticate

Conversation

@marcvs

@marcvs marcvs commented Aug 3, 2026

Copy link
Copy Markdown
Collaborator

No description provided.

@zachmann

zachmann commented Aug 3, 2026

Copy link
Copy Markdown
Member

While it is an easy and small fix, I'm not sure if it should be done.

--reauthenticate is meant to do a reauthentication with the current settings, I would argue that if you want to change things on the account, like scope, then you should do that. You would do that with oidc-gen -m.

If one would like to have scope in reauthenticate, the question is where to stop. Why only scope, why not aud, ...?

@marcvs

marcvs commented Aug 5, 2026

Copy link
Copy Markdown
Collaborator Author

No. This is not what one (I) wants. This creates an unnecessarily large number of configurations, simply because I want to add or remove a scope.

Currently, with ssh-oidc scopes need to be adjusted. When I try 10 times, I end up with 10 different configs.

Also, --scope remains optional.

@zachmann

zachmann commented Aug 5, 2026

Copy link
Copy Markdown
Member

I do not really understand. This should not create additional configurations. With oidc-gen -m you can edit an existing configuration (also the scopes), and it will update the existing account configuration. That should be exactly what you want (if you want to change the scopes for an account config).

@olifre

olifre commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

An alternative proposal (but I also did not fully understand the use case yet):

Would it be helpful to allow performing token exchange with oidc-token which allows changing scopes with most IAM systems, so in case a token for a login is required with different scopes than in the account configuration, this could be handled by performing token exchange and fetching a token with the necessary scopes this way?

As far as I know, oidc-token is not yet able to perform token exchange, though (please correct me if wrong). But in case scopes need to be adjusted often and the IAM system allows for that via token exchange, this could be a way to go?

@marcvs

marcvs commented Aug 5, 2026

Copy link
Copy Markdown
Collaborator Author

oidc-gen -m egi --scope "eduperson_assurance entitlements profile openid offline_access" asks me for a client_id, and client_secret I don't know them, it was a public client. I think.

Pushing a lot of work on the user is what I try to avoid.

@zachmann

zachmann commented Aug 5, 2026

Copy link
Copy Markdown
Member

The oidc-gen will prompt the user for all information so he can change it, if he does not want to change some aspect, just hit enter to keep the current value (suggested in brackets). For public clients include --pub.

@marcvs

marcvs commented Aug 5, 2026

Copy link
Copy Markdown
Collaborator Author

Imagine I'm a client app (oinit, mccli) that uses the oidc-agent lib. I find that the AT does not have the sufficient claims for my app. I'd then go (and hope, and keep fingers cross, I know) and ask the user to request more scopes, so the claims I need are contained.

I want to tell the user: "claim_x is missing, please add it by running some oidc-gen command (I was thinking oidc-gen --reauthenticate <shortname> <list of scopes that I need>)

Is this realistic? I know I'll probably need to maintain the "scope -> claims" list in every client app.

Of course, I could oidc-gen -p, parse the json, and show the detailed command for oidc-gen -m <shortname>, but given the simplicity of the patch, which I think does not break the current --reauthenticate flow, I'd go for that.

@zachmann

zachmann commented Aug 5, 2026

Copy link
Copy Markdown
Member

I understand the use case. But I think the solution approach is slightly wrong. --reauthenticate is only mend for a simple re-authentication with no config changes. It is for the case that the RT expired and the user needs to re-auth.

If one needs to make modifications to the config this is done with -m. Including --prompt=none will eliminate the prompting for other things. So the following should work in your case:

oidc-gen -m egi --pub --prompt=none --scope "openid profile email"

However there are still some caveats:

  • currently oidc-gen requires the user to either provide a client-secret or --pub. But the other application will not know if a pub client is used or not. But oidc-gen should already know if a pub client was used. So it should not prompt for a client secret in that case (if users want to add one, they would need to provide it via command line flag).
  • The other application can only create the oidc-gen command if it already knows the account shortname, if it was requesting an AT by issuer url it does not know that.

@marcvs

marcvs commented Aug 5, 2026

Copy link
Copy Markdown
Collaborator Author

And I need logic to understand if the client was created via a public client or not.
Could I add an option --alter or --change, which does my "reauthenticate" and also supports new --scope(s)?

@zachmann

zachmann commented Aug 5, 2026

Copy link
Copy Markdown
Member

As I have written

But oidc-gen should already know if a pub client was used. So it should not prompt for a client secret in that case.

That's something that needs to be changed. But with that the -m should do what you want. I agree that a --edit makes sense, but IMO this would be an alias to -m since it would not do anything different.

@zachmann

zachmann commented Aug 6, 2026

Copy link
Copy Markdown
Member

We discussed this out of band. I will add support for auto detecting the pubclient with existing account configs. And then oidc-gen -m is sufficient.

@zachmann zachmann closed this Aug 6, 2026
@zachmann
zachmann deleted the add-scope-on-reauthenticate branch August 6, 2026 08:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants