Frequently asked questions

Authress technology

Access Record

A record combines users, permissions, and resources into a list of statements. A statement contains at least one of each, and actually grants permissions to users. These access records are groups which allow multiple users, multiple resources and multiple roles making it easy to create templates and mix and match access. Every time a resource is created in your platform, an access record can be created to encompass the new resource permissions that go with it.

Role

A list of permissions. A role combined with a user and a resource gives that user the all the role's permissions for a resource. Roles are resource and user agnostic. A role containing the permissions Read:Record and Update:Record, could be attached with a user UserA and resource RecordB giving the user read and update permissions to that record. Roles provide an abstraction layer between permissions and authorization checks so that service applications can perform consistent checks and roles and can be create, updated, and assigned independently changing what users have access to without ever updating code. Making roles more granular or combining roles is easy, and users never lose permissions and can be done all from the Authress Management Portal.

Authorize user check

Make the API call with a user, permission, and resource to verify if a user should be allowed to perform the associated action on the resource. If a user has Allow to a permission on a resource then they can perform the action, if a user has Grant or Delegate then they have access in Authress to assign Allow to other users.

OAuth technology

What is OAuth and what does it have to do with identity or access control?

Nothing really. OAuth supports delegation, that is allowing one entity to present itself as another entity in a way which everyone understands. Most services do not need delegation, they only need authentication. That is, your users identity themselves to your app in a way in which you can verify. The users do this by obtaining access tokens and presenting them to your service. Your service then verifies the authenticity of these tokens. The process the user navigates to obtain a token may or may not use OAuth.

What are ID Tokens?

Id Tokens are a JWT that contains user identifying information in a consumable format. Consider them to be an optimization on taking a user access token and calling the api GET /users/${userId}/profile and interrogating the response. ID tokens are available for inspection, they are never meant to be used for authentication (even though Google login incorrectly asks that apps use them).

What are Refresh Tokens?

In order to understand refresh tokens first we must understand delegation. In most apps, there is no delegation, therefore refresh tokens don't have any meaning. So let's first look at delegation. A good delegation example includes--your user, your app, and a third party resource such as a Document Repository. Your app wants to directly access the user's document in the Document Repository. To do this the user must grant your app access. There are two ways to grant access:

1. The third party app resource grants your app permission and stores this permission in the third party service. This is the preferred way, and after this happens, your app can request resources as it normally would. Your app has access to all resources for all users that have granted it access.
2. The third party app resource gives your app a unique token for every user. The third party does not store any data and instead delivers a verifiable token to your app. This token allows your app to impersonate the user, and therefore must have a different token per user. This token is the refresh token and should be treated as you would treat a password. This token is not an access token, just as a password is not an access token. Your app uses the refresh token to get an access token. The refresh token is in other words a client password.

What are Scopes?

If you don't need delegation then they don't serve any purpose. Scopes are another name for the delegated permissions that show up in the refresh tokens. A user decides what scopes to delegate to your app to access the third party. You cannot limit which scopes the user allows the refresh token to have, this is their decision. Using scopes for permissions to restrict the user's actions therefore is a security risk, they are there to restrict the actions the app can perform while impersonating the user.

Architecture

How to best design a future-proof system?

Well... this is one of the critical issues to sort out, which means it is the right question. It's the primary reason we built Authress, because we felt that existing solutions blocked further implementations. There are a couple of things here:

• If all data is always owned by a single user, using JWT based permissions can work otherwise having a more robust system can more important.
• The second part of this is, that's what you are hoping a provider offers. If you make a mistake with how you set up your resources and their permissions, how easy is it using that provider to make changes to your model over time. If you build it yourself, you'll very quickly run into to the caveats presented in building your own authorization article. Authress focuses on making migrations as easy as possible and if necessary will support whatever changes make sense. Using a SaaS provider shouldn't punish you for making one of these sorts of mistakes, instead it should accountable for helping users to remedy access control models to match the needs of the system.

How do I actually implement CIAM access control?

There's at least two parts to any CIAM system--checking permissions on existing resources, creating new resource permissions. Both of these are outlined in when getting started with Authress, which specifically are--authorize user and create access record.

Should authorization happen in a API Gateway?

An example implementation might look like this:

There's a UI and associated backend that calls multiple internal services, these services don't have any knowledge of the user. However, the UI and associated backend have the permissions and business logic. These might also be considered a Gateway that explicitly checks permissions. (Another implementation of this is a service mesh, which has similar issues.)

The problem with this is that the underlying services:

• Can never have their own permissions -- Doing so obsoletes the checks in the gateway, and duplicates verification.
• They can never be used outside of a context where there is already an existing service in front of them -- They don't have their own permissions so therefore aren't reusable
• And most importantly, the Gateway service needs to make decisions fully knowing how all these underlying services work and which data they could expose -- Thereby creating a tight-coupling between the gateway and the internal services. If an internal service has PII that shouldn't be exposed then the Gateway needs to do know to add a permission to stop it. Now user data security is split across services creating opportunities for data regulation violations.

How do I avoid coupling my permission model to a service provider?

Absolutely, it should go the other way, but there are always challenges to overcome. For instance the Authress value-add is: we support your permission model. There are some advantages to utilizing a service providers model, however. For instance a model might not stand up to rigorous changes that could come down the line in the future, so in some cases building out to a provider's specification makes sense. In the end this is always your decision, and if you want to migrate data in or out of Authress, we will help do the heavy lifting.

Complex scenarios

Does Authress do WebAuthN, App Catalogs, or support internal employee workforce?

Yes.

By workforce employees we mean assigning and giving internal users access to internal apps or SSO to external services, also known as an app catalog. As a customer of Authress, you have your own IdP for your users and integrate those external apps directly into the IdP. Most of our customers have their own AD/google workspace internal IdP and don't need something complex on top. However, in these more complex scenarios Authress supports them. Easily add WebAuthN, Login with Passkeys, or SAML and Application Catalogs to your infrastructure.

Additionally, Authress focuses on delivering a plugin CIAMaaS for companies' user facing products, in most cases this means supporting your products' end-users to log in and authorize. Since almost of those users want to login via SSO with their existing corporate auth, Authress supports these use cases out of the box. If these users are also employees, it's easy to set that up with our Authentication configuration and Application Catalog.

What's the best way to migrate 10K or 100K user permissions

It happens that systems evolve, and minor decisions at one point can have a big impact and bottleneck future development. With Authress migrations are easy. Fundamentally, the permissions-role duality encourages easy changes to existing roles as new permissions and resources pop up. However, there can be more complicated changes that aren't so easy to visualize. Role changes can be done in place and will automatically take affect; other changes might need some additional thought include:

• Reassigning user roles - Where there was once one role (A) assigned to a group of users, now two roles (A1 and A2) are necessary.
• Changing a resource hierarchy - A resource needs to be relocated from /resources/A/sub-resources/1 to /resources/B/sub-resources/1

Since the roles are only logically grouping of permissions in this scenario, you might be able to perform an in place migration by changing the existing roles. However, the important question is what do you want to with the users who are currently assigned the original role A. Best practice is leaving those assignments untouched and proceed to have three roles. The reason here is that you can ensure that current users don't accidentally losing access to something critical for them. And over time users with role A can be manually migrated to roles A1 and A2. Choosing this route allows for you to monitor the usage of deprecated roles.

The role migration process:

1. Add the two new roles A1 and A2 and specify the correct permissions for them
2. Update services that reference the deprecated role A to now reference the new roles when they make associated changes to access records.
3. [Optional] Migrate any existing users to the new roles A1 and A2 by updating their access records
4. Delete the deprecated role A

Given that, if you still decide you want to perform a mass migration to swap out roles for any reason, that definitely falls under an migration the Authress development team usually runs for free. 10K or 100K users or access records is a low volume change and can be scheduled with some notice. If you find yourself in specific situation more than once, it's worth reaching out the team to get an architectural review of the data model to help avoid unnecessarily complex migrations in the future.