Every auth question answered

Frequently asked questions about authentication and authorization

Common terminology

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.


A simple 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.

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 like 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.

How to best design a system in order to not be blocked by implementation details in the future?

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:

How do I actually implement IAM access control?

There’s at least two parts to any IAM 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.

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.

Since you're here, check out what Authress is all about!

Enjoyed reading this article? There's more in our Knowledge Base.