Do you considered simply adding an extension point which allows to call the /userinfo endpoint of an identity provider` with the provided token?

That way the same data would be available like on the "normal" login. The token would be set in the auth-backend and mapped to the user.

This would have less risk as the Oauth2 device flow is maintained by dedicated products.

Could you elaborate? Do you mean being able to for example call /google/userinfo with a Google access token and get back the Backstage user info?

Not sure how standardized device auth implementations are tbh. Judging by many of our current OAuth integrations that would likely get really messy for the clients.

Another downside that I covered in #30066 is that proxy auth is often the best option for auth, and that session can't be forwarded. That said we could always require a secondary login for device flow to get around that.

The userinfo endpoint is part of the OIDC standard so it can be expected that most identity providers provide such an endpoint. AFAIK the userinfo endpoint returns the same information as with the login. Therefore this flow should be possible.

With externalAccess setup with a JWKS:

sequenceDiagram
User->>IDP: login / fetch token
User->>Backstage: API request with IDP token
Backstage->>Backstage: check if token has been validated before
Backstage->>IDP: call /userinfo endpoint and fetch details
Backstage->>Backstage: run signin resolver and apply permissions
Backstage->>User: return API response

Not sure how standardized device auth implementations are tbh. Judging by many of our current OAuth integrations that would likely get really messy for the clients.

With that application Backstage would not really care how the user obtained the token. In that case it would be more an ( optional ) extension of the externalAccess configuration.

That's roughly how the regular auth flow works today, but I don't quite see how it helps us with device auth? Device auth requires more of an ability for clients to initialize a decoupled auth flow that users can then approve, rather than initializing auth directly. In this flow the "login / fetch token" step would need to be the device auth flow, initialized towards Backstage. There would then be a second client that completes it towards Backstage and/or the IdP.

That's roughly how the regular auth flow works today, but I don't quite see how it helps us with device auth?

Yes, that is the reason why I'm proposing it. The IdP would implement the actual authorization part and Backstage would have not to implement it as it its not the core functionality. IMO this should be offloaded as much to dedicated tools e.g. Keycloak or commercial offerings.

Device auth requires more of an ability for clients to initialize a decoupled auth flow that users can then approve, rather than initializing auth directly. In this flow the "login / fetch token" step would need to be the device auth flow, initialized towards Backstage. There would then be a second client that completes it towards Backstage and/or the IdP.

I think this is the question should Backstage fully implement the Device Flow or should the externalAccess JWKS option be extended to make use of the permission system.

backend:
  auth:
    externalAccess:
      - type: jwks
        options:
          url: https://another-example.com/.well-known/jwks.json
          issuer: https://example.com
+         userInfoPath: /userinfo

Alternatively a externalAccess type oidc:

backend:
  auth:
    externalAccess:
      - type: oidc
         options:
           url: https://another-example.com/

I think in the end both would work. So also happy if Backstage implements the DeviceAuth flow, but I simply think this will pull a lot of resources security wise 😄