Hacker News Reader

Comment by colemickens | Hacker News Reader

Here's my problem with OIDC and I don't know where to bring this up to find out if my hopes are widely off or I've missed something big and it already exists...

There's nothing specified anywhere that allows an application to interrogate an RP about the available scopes. I just don't see how fine-grained resource access can be done with OIDC without requiring the user to grant much coarser access first. I found a draft spec once but it was abandoned and the author didn't reply to an email I sent...

View on HN

If you make a request without a token (or with an insufficient token), the resource can respond with the required scopes. As in:

WWW-Authenticate: Bearer realm="example", error="insufficient_scope", scope="view_topic"

In terms of a map of what scopes are required for all resources on a site - unfortunately just like other non-RESTful things that is conveyed outside of the interactions today via something like OpenAPI descriptors and documentation.

The AS can convey a list of requestable scopes in its metadata. There were specs like host_meta which could have been easily leveraged to do the same for a resource server, but I am not sure host_meta actually went anywhere.

And a problem for the Resource Server: no common way to check the validity of a token. You may be lucky and get a JWT but even then there's no specified URL to get the keys to check it. Usually you get an opaque token and hope the client gives you a way to know where it comes from so you can do some specific server to server call.

So you can't implement an independant RS which does not care about clients and how they authenticate their users.

Look at the JWT, take the issuer claim, take the .well-known config off that url, and you have keys. Match that against the known permanent issuer you expected, and verify the signature of the JWT against the keys. If you're accepting things that aren't JWTs then you're not doing oauth.

> If you're accepting things that aren't JWTs then you're not doing oauth.

As a resource server: https://tools.ietf.org/html/rfc6749#page-10

Access tokens don't have to be JWT. And some OpenID authentication server give opaque tokens: your resource server has to know how to call it to check the token and get some user infos if available.

Yes, I misread and typo'd.

Only OpenID Connect has a guarantee that it will issue a JWT token (and only the id_token). OAuth allows access and refresh tokens to be opaque to the client - e.g. either:

- a value only the AS understands (in which case the protected resources will need to use an API to introspect them) - a format that both the AS and protected resources can understand (such as a legacy crypto format, a COSE token, or a database key)

If your client has to pull apart an access token to extract information and make a decision, you are doing OAuth wrong. In particular, that client code will never work against another AS, and it is more fragile than normal against changes on the AS.

Yes, I misread and typo'd, thinking OP was talking id_tokens and OIDC. Completely correct on the last para, I spend quite a bit of time convincing partners of this.

That's what the Introspection endpoint should be for.

But it is the problem of Oauth 2.0. Every implementer has a choice for lot of things.

When you get a token you are not sure to get it as a JWT. If it is a JWT, the issuer is not enough to know what endpoints it provides.

You still have to care about your clients authorization provider so you can check their access tokens. But you're building a resource server: you should not have to care about all this. Creating a resource with this identity from this issuer? Go ahead. Want to access it again? Let me check your token using this standardized token: I don't have to know if is issued by Google, the Canadian Government or your own personal server.

One of the complexities that a lot of people don't realize is that the roles involved in OpenID Connect and OAuth are different - OpenID Connect only minimally involves resource servers (in that they can use an access token to hit the user info endpoint to get information on the user session.)

With OpenID Connect adds things like dynamic client registration for a client (acting as an RP) to get authentication information, and you can use OpenID Connect to get both that authentication token and an access token at the same time.

However, this unfortunately doesn't extend to weakening the dependency on a protected resource receiving one of these access tokens needing a relationship with the issuing AS.

Unfortunately, dynamic client relationships haven't caught on enough for there to be focus on this issue. But on the flip side, there would be a lot of other agreements around what those access tokens mean and what API they can apply to before you could have such a dynamic authorization relationship.

Now, if the goal is for _your own_ protected resources to rely on authorizations provided by other ASs - likely you just shouldn't do it that way. Instead, you should have a local AS that itself has relationships with multiple other ASs acting as an intermediary (or what Microsoft has historically called an STS). It authenticates based on other providers, gets their authentication and access tokens, and translates them into tokens that the local environment can understand based on a single, centralized policy.

Reply on news.ycombinator.com