API / System Design [Flexible Authentication / Authorization]?


We’re a smaller shop that puts out a number of products that require
authentication and authorization. We’re currently using a 3rd party
service to “spin up new auth APIs” for each application. However, I
would like to investigate potential designs for doing this ourselves
in-house due to additional security requirements that may be needed in
the future. I’ve included information below and would appreciate any
design or support as I’m relatively fresh with designs of this scale.

Summary of goals:

An interface that allows a developer to create and manage
authentication APIs for multiple applications via a webpage. This
includes the mostly automated process of spinning up new auth APIs,
and ideally the ability to do some form of RBAC / ABAC changes via
this page.

Acceptable ‘Limitations’:

  1. All APIs can expose the same common-auth endpoints, so they’re basically just “Images” of one another. (I.e. Login / Register / etc.)

  2. While this would ideally be entirely automated, some parts I’ve thought of being manual are:
    * Domain configuration (pointing subdomains to new endpoints)
    * Spinning up additional VMs (needed?)
    * Spinning up additional DBs or tables?
    * Minor configuration changes
    * others I haven’t thought of?

User Stories:

  • As a Developer, I want to login to a web portal so that I can manage auth APIs.
  • As a Developer, I want to create a new API in the web UI, so that I can then integrate it to new applications.
  • As a Developer, I want to manage users in the web UI, so I can oversee access to our applications.
  • As a Developer, I want to **…

Future Considerations:

Each new API for the applications should likely have the user stores
(table containing user information) segregated into different
databases stored on separate hardware to minimize attack vectors and
improve security/scaling. For now, I’m thinking of different
subdomains or maybe request parameters to separate the APIs?


I feel like there may be some solution that involves building a
template/image of an Auth API on Azure and just duplicating the VM or
image, but I’m not too sure of this route either. Obviously
management, maintenance, updates, etc. to these would be more
hands-on, but feel free to provide feedback on this as well.

Thanks in advance!

Go to Source
Author: ClicheCoffeeMug

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",
    "scope":"openid ..."

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

Go to Source
Author: Jorge Leitao