OAuth2 not implicit flow, POST username and password

I am a mobile dev, now for a project need to authenticate with a backend service using identityserver4 and OAuth2.

The project has things set up so it is using OIDC for authentication.

BUT

It is on a “password” flow, so is not implicit flow (login on a browser to FB, Google, and come back to the app after that).

So basically I just ended up using fetch request to do a POST to the server with the username and password…
Then get token and refresh token and take it from there…

So, my question is, what is the benefit of using OIDC? if the username and password will be sent anyway? (HTTPS)

Is this a common thing? I couldn’t find a library on react native for OIDC that didn’t use the browser. The most similar thing was a library on node

Go to Source
Author: manuelBetancurt

Centralized authorization – via token or endpoint?

Firstly, I want to clarify the title. After spending a few weeks now tackling centralized identity I have found a lot of differing opinions and implementation of authorization (permissions). Mainly, there seems to be 2 ways I see it done

  • Store roles, and sometimes even strict permissions, in the access token (or some token associated with whatever protocol you are using). The upsides are ease of distributing this data to the client and resource, and security. The downsides are a potentially large token, and immutability of JWTs cause potentially out-of-date information.
  • Provide a centralized authorization server, or simply use endpoints on the identity server itself to serve specific authorization information, kind of like /userinfo but for authorization information. The upsides of this are up-to-date information and a clear separation of concerns. The downsides are a lot of calls to this endpoint, the fewest being one call per request as far as I can tell.

I see Auth0 allows a way to update token data on the fly (permissions, avatar, etc.) which is really convenient, however what are the downsides of using JWTs this way? I am confused as to why these protocols (OpenIdConnect, etc.) do not implement some way to force a token refresh, and thus a refresh of claims. I may be overthinking this, but what if a reference token was used, and we marked it as out-of-date? I mean, if we can mark a token as revoked then surely we can use some trick to mark it as stale? The client then would have default logic in this scenario to use its still-valid refresh token to receive a new access token. I feel like the utility of this whole system is really brought down by the fact that refreshing isn’t supported. Even if it was a separate permissions token, is this a valid idea? It just seems much more convenient than the latter.

For the second point, when using separate authorization and calling and endpoint for this info there are a few problems too. While I don’t know how PolicyServer’s paid version works, the OSS version uses this methodology. My problem with it is that the overhead of an http request is added to almost every page load, button click, etc. Using a refreshing JWT theoretically sounds like a nice way to only force a refresh when claims information is changed for a specific user only. In addition to this, basically every client and resource will need to know this claims information. While the resource itself should use authorization information, the client is still going to need to dynamically show/hide content based on this info as well. How do we easily share this information without having both the resource and client(s) request this information on every action? In PolicyServer’s demo, it’s just a bare client using authorization information from the API endpoint, there is no resource involved, probably because it was a complicated issue.

Is my idea in the first point of marking a reference token as stale practical? It would take a lot of work and would have to override existing interfaces both on the server and client. However, I just cannot see a dedicated authorization endpoint as a possibility given the concerns above. I’m still perplexed as to why none of these protocols have an easy way to refresh claims information after specific actions.

Go to Source
Author: perustaja

Is it ok to share relevant login information on an API’s public endpoint?

I have an (https-only) API that uses OAuth2 for authentication and authorization via access tokens.

Any request to the API needs an access token to the Authorization header. The API validates that this access token is signed by a specific tenant (e.g. google), is targeted to a specific audience, and has some specific scopes.

As a user/service, it would be really helpful if the API would expose, on a public endpoint, such information, so that I know from where I should fetch an access token from (e.g. through PKCE), and which scopes I need to request the token from.

A natural mechanism for this is for the API to have a public endpoint with something like

{
    "provider_uri": "https://accounts.google.com/.well-known/openid-configuration",
    "client_id":"...apps.googleusercontent.com",
    "scope":"openid ..."
}

Is this a valid approach? What other relevant idioms exist to address such problem?

Go to Source
Author: Jorge Leitao