Identity Concepts Demystified — Part 2 — What are OpenId Clients?

Identity Server

This is the 2nd installment from a series of posts that I am going to write about Identity especially when it relates to various Identity Servers available. If you haven’t looked into my previous post, it can be found here.

Auth0, Okta, Azure Active Directory are commercially available options. IdentityServer is an open source option available as well.

In this article, we’re going to talk all about Clients. In Part 1, we spoke about Resources, and how to set them up so that they can be protected. In this post, I will focus on building Clients that will essentially signal the Identity Server to grant access to these resources.

What are Clients?

Clients are a means to grant access to resources.

That’s literally all there is to know. Clients are applications that allow consumers access to the API Resources that are protected. The access is granted in the form of a “token”. More on Tokens in Part 3.

Clients could be Machines, Browsers or Native Applications anonymously accessing resources or a on-behalf of a user logged in requesting access to the protected resources.

Your client setup could totally vary depending on the manner in which you wish to access protected resources. For e.g. a Client implementation for a Native Application is completely different from that of a Javascript Browser based application. A M2M (machine-to-machine) client access also requires a completely separate setup.

A client typically has:

a) a client id — to uniquely identify the client

b) a secret — if needed to establish access. In unsafe scenarios, a secret can be optional, provided there’s a…

c) redirect_uri — for the identity server to direct the token information to. This helps when secrets cannot be divulged. Especially in Javascript apps where nothing is a secret.

d) scopes — request the rights of what the client can have access to.

e) response type — if set, will allow defining the expected token type.

f) offline access — if used, will return a refresh token in return that will allow the access tokens to be refreshed over and over again.

g) token lifetimes — usually, depending on the type of the client, you can change the lifetime of various tokens (namely id tokens, access tokens, refresh tokens, authorization codes etc.). These are generally standard an should not be messed with, but can be good options.

h) CORS restrictions — I could setup access to specific resources from specific origins only.

What is a Grant Type?

A grant type defines the mechanism of communicating with a Client. There are numerous different grant types to choose from. Here are some:

1. Client Credentials — This is primarily used for M2M and in environments where we know that the chances of exposing a password (or a secret) are relatively low.
2. Implicit — This is primarily used in Javascript browser environments where there’s no such thing as secrets. This approach requires the Identity Server to call back a pre-configured URL that it can post the secrets to in real-time. In implicit flows, tokens (or more specifically an Id Token) are passed to the browser directly.
3. Hybrid — Provides best of both worlds. One can request Id Token using a browser, and request a more detailed token called “access token” using a back-channel server channel.
4. Password — This is semi-retired. In this scenario, a resource owner passes his username and password to the Identity server. The identity server then validates the user and then grants a token. This approach should be used sparingly. Mostly used in scenarios where one doesn’t want to redirect the user to an Identity Server for login and instead pass login credentials directly to the Identity server.

Why do Clients matter?

Firstly, clients define the access to the protected resources. The Identity server flow of information offers directly based on the client configuration.

Secondly, clients allow restricting (or granting) access to protected resources. As an admin, I could easily configure an application to have “read-only” rights whereas grant other to have “admin” rights. I could also setup valid ORIGINS (CORS) based on client’s needs. This essentially lays down the foundation for tighter controls.

Google Calendar API for e.g. allows you to build a Browser Client, or a Native Application Client or a M2M Client and automatically pre-configures a bunch of settings based on the type of the client. You could also define the limits of your client through scopes.

That’s all there’s to know about Clients. Identity Server makes it very easy to add these clients (either programmatically) or using a managed application.