问题
In one of the application at my work, we are thinking of just using id_token for all the use-cases including authentication and authorization. The solution is being developed from scratch right now. There are currently no consumers of any resources and we can modify the resources to use id_token. I am bit new to the concepts of openid_connect and oauth 2.0. Will there be any issue of just using id_token having all the access details?
回答1:
If your application needs just to authenticate users and then let them access its backend with all the features they may access, it's easier to use just an ID token and check access rights based on username or roles. When using just an ID token, you can also accept ID tokens from different OAuth2 providers.
Access tokens are useful for partial access delegation - when users delegate some of their permissions to another application. For example if I create an application that asks its users for a read-only access to their GMail, the application can get the access without it being allowed to access any other Google resources of the user.
If you wanted to use an access token for a simple client application and its backend, your client application would have ask for all OAuth2 scopes it can possibly use and then see what scopes come back in the access token it gets from the OAuth2 server.
So if you want to create your backend API just for its frontend and don't plan to open it for other applications, it's easier to use just ID tokens. If you find out that you need access tokens, you can start using them later.
You can also consider issuing your own tokens (JWT) with all authentication and authorization info you need based on a provided ID token, so your backend doesn't have to fetch the user's security data on each API access.
回答2:
I'd recommend following the OIDC spec as designed (i.e. use access_token rather than id_token for resource server authorization) to prevent opening yourself up to security vulnerabilities.
There's a good discussion here about using id_token as an access_token: https://github.com/IdentityServer/IdentityServer3/issues/2015#issuecomment-147527823
The spec is designed for the id token to be used in the client and the access token to be used at the APIs. I'm sure you can come up with some alternative protocol to re-use the id token, but OAuth2 and OIDC just didn't evolve that way. I'm sure if they were all designed from scratch they'd look different.
As for "is it safe to pass the id token to the backend" -- not sure. I really haven't scrutinized the attacks against it or how it could be manipulated or fooled. The spec authors do that sort of thing, and that's why we tend to stick with their lead since they've spent many more hours on it then I have.
Question, why would you use id_token rather than access_token? It's easy to get a real access_token so why go against the spec?
回答3:
All authorization is local. What that means is that the server with the resource to be shared needs to have the information is needs to make the decision to release the resource, or not. So the question is; does the id_token have sufficient information with the required level of assurance to make the authorization or not. That is the only real question here.
来源：https://stackoverflow.com/questions/45564948/openid-connect-is-it-fine-to-use-id-token-as-access-token