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

.well-known/openid-configuration for system_accesstoken #89

Open
sachip-msft opened this issue Apr 21, 2022 · 6 comments
Open

.well-known/openid-configuration for system_accesstoken #89

sachip-msft opened this issue Apr 21, 2022 · 6 comments

Comments

@sachip-msft
Copy link

Is there any documentation on how agent variable $(system.accessToken) value can be validated in custom API? the JWT contains x5t header however with no location of issuer signing keys, it cant be validated.
The token contains values like this but where can we get issuer signing keys in this case? the issuer is app.vstoken.visualstudio.com
Does anyone know what is endpoint for openid configuration for this endpoint?
should have something like /.well-known/openid-configuration

image

@gerritlansing
Copy link

Would also love to be pointed to the openid-config so that we can validate these tokens externally.

@flyingUnderTheRadar
Copy link

Were either of you folks able to get the endpoint that can be used to get the certs to validate the signature?

@gerritlansing
Copy link

@flyingUnderTheRadar Confirmed with MSFT there’s presently no public endpoint. Explained my use case to the product manager and hoping to see this at some point.

@flyingUnderTheRadar
Copy link

Thanks for letting me know. I guess the only other slightly undesirable (dependency on an unnecessary endpoint) way is to send this token back to Az Devops in an API call and let them do the heavy lifting to make sure it is a valid token.

@gerritlansing
Copy link

gerritlansing commented Feb 22, 2024

@flyingUnderTheRadar I just had an idea occur and I tested it out. Microsoft recently released service connection federated authn support for Azure Resource Manager, which uses an app reg federation rather than client secret. I built a quick pipeline to see if I could nab that token and validate it externally.

I configured a service connection to use Workload Federation to an App Reg in Azure AD with no real permissions (could probably lock it down further to prevent a stolen token from being used in Azure AD).

Sample Pipeline

trigger: none

pool:
  vmImage: ubuntu-latest

steps:
- task: AzureCLI@2
  inputs:
    azureSubscription: '<ServiceConnectionName>'
    scriptType: 'pscore'
    scriptLocation: 'inlineScript'
    inlineScript: |
      echo $env:idToken > $(Build.ArtifactStagingDirectory)/token.txt
    addSpnToEnvironment: true

- task: PublishPipelineArtifact@1
  inputs:
    targetPath: '$(Build.ArtifactStagingDirectory)'
    artifact: 'token'
    publishLocation: 'pipeline'

Example Token Payload

{
  "jti": "<guid>",
  "sub": "sc://<DevopsOrgName>/<ProjectName>/<ServiceConnectionName>",
  "aud": "api://AzureADTokenExchange",
  "iss": "https://vstoken.dev.azure.com/<GUID>",
  "nbf": 1708639268,
  "exp": 1708640467,
  "iat": 1708639868
}

Accessing https://vstoken.dev.azure.com/<GUID>/.well-known/openid-configuration provides the jkws_url linking to the public keys, which permit verification of the signature.

It's not pretty, but I think it be secure and as long as the app reg in Azure AD is configured to to only allow federation from Azure DevOps, has no Azure AD permissions, and the service connection is tightly controlled.

@flyingUnderTheRadar
Copy link

I can't use this for my use case but yes this is a good workaround!

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