Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong identity provider #970

Closed
laurentsimon opened this issue Apr 12, 2024 · 8 comments
Closed

Wrong identity provider #970

laurentsimon opened this issue Apr 12, 2024 · 8 comments
Assignees

Comments

@laurentsimon
Copy link
Contributor

Description

I signed (using the API) with a Google account, and the OIDC token issuer shows https://oauth2.sigstore.dev/auth. I expected the value to be https://accounts.google.com.

Verification works when passing my email as identity and https://accounts.google.com as the identity provider.

Version

At main

@laurentsimon laurentsimon added the bug Something isn't working label Apr 12, 2024
@woodruffw
Copy link
Member

woodruffw commented Apr 12, 2024

I signed (using the API) with a Google account, and the OIDC token issuer shows https://oauth2.sigstore.dev/auth. I expected the value to be https://accounts.google.com.

Could you share the API calls you made? If you used Issuer.identity_token() and went through the interactive flow, that took you through Sigstore's Dex instance rather than directly through the Google OIDC IdP.

Edit: to be more precise: if you want to use the Google OIDC IdP directly, I believe you'll need to construct Issuer(base_url) where base_url is the OIDC base URL for Google (I think this might be https://accounts.google.com/, but I'm not sure). By default sigstore-python will always go through a Dex instance, to give people to opportunity to pick one of several supported IdPs.

@woodruffw woodruffw self-assigned this Apr 12, 2024
@laurentsimon
Copy link
Contributor Author

Gotcha. The main problem is that the CLI / API (for model signing) is generic and I don't know ahead of time which IdP users will be using. I think what I'm after is some UX improvement. Thinking more about that, I should be able to extract the IdP from the cert after signing occurred. That would resolve the problem. Feel free to close this issue and I'll fix it in our codebase. Thanks

@woodruffw
Copy link
Member

Ah yeah, I think a variant of this has cropped up before (#567?) -- if you need to stop the user from signing using an OIDC issuer other than the one you expect but you can't stop them from performing the OIDC flow itself, you should be able to introspect on IdentityToken.expected_certificate_subject. Does that help address the case?

(cc @jku since he also hit this, IIRC)

@susperius
Copy link

I ran into the same issue. Is there something that contains the real issuer? (i.e. Google)

I'm using the issuer.identity_token call to retrieve the token with the issuer being the production instance.

@woodruffw
Copy link
Member

woodruffw commented May 13, 2024

I ran into the same issue. Is there something that contains the real issuer? (i.e. Google)

It's mentioned directly above: IdentityToken.expected_certificate_subject.

For example:

>>> from sigstore import oidc
>>> issuer = oidc.Issuer.production()
>>> token = issuer.identity_token()
Waiting for browser interaction...
>>> token
<sigstore.oidc.IdentityToken object at 0x102673230>
>>> token.expected_certificate_subject
'https://accounts.google.com'
>>> token.issuer
'https://oauth2.sigstore.dev/auth'

@woodruffw
Copy link
Member

(I don't remember why it's called the "expected certificate subject" rather than "federated issuer" or similar. It might make sense to rename it.)

@woodruffw woodruffw removed the bug Something isn't working label May 13, 2024
@woodruffw
Copy link
Member

I believe this is fully addressed by pre-existing APIs on IdentityToken, so closing 🙂

@woodruffw
Copy link
Member

I've opened #1016 to rename this API. That change will be included in the 3.x series.

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

No branches or pull requests

3 participants