Harmonizing OAuth2, OIDC and SCIM

faucet trumpet

The Cloud Foundry blog recently published my post about how we combined OAuth2, OpenID Connect,  and SCIM in the User Account and Authentication (UAA) service. The UAA and those three protocols are now woven into the Cloud Foundry platform on many levels:

  • authentication and authorization of developers managing applications on the platform
  • single signon for developers with platform support sites
  • delegated authorization to partner applications and services
  • support for separation of duties for service to service access between platform components.

The UAA also allows us to seamlessly support external authentication services such SAML, OpenID2, — and, yes, even LDAP.

I’m pretty happy with how the harmonization turned out. Each protocol contributes specific, essential capabilities with very little overlap. The usefulness of the whole is greater than the sum of the parts. As we move forward, there are some areas of concern:

1. Schema

OAuth2, OpenID Connect, and SCIM have similar schema, but there are
a few odd quirks which require translation. Compare SCIM userName with OIDC preferred_username, or SCIM name.givenName and name.familyName with OIDC name, given_name, family_name. PhoneNumbers and emails have similar issues. It’s not just the minor variation in attribute naming styles — a little camelCase to snake_case translation code could handle that. The issue is that OIDC attribute names are case-sensitive with single values, whereas SCIM attribute names are case-insensitive and can be multi-valued with sub-attributes.

SoClose and yet_so_far.

2. Future Expansion

Each protocol currently provides fairly focused functionality and there is very little overlap. However, standard protocols tend to grow and expand in scope. One way that a working group can accept a current revision is by getting some members to agree to postponing features until a future revision — which implies that there will be expansion. For OAuth2 and OIDC some of the natural areas for expansion are management of client registrations and access to user information in non-interactive scenarios. The working groups have discussed adding both capabilities. Both are areas that we implemented with SCIM base or a SCIM extension. It would be very nice from an implementation standpoint for these protocols to remain complimentary rather than expanding until they overlap.

Managing how well identity protocols play together is not exciting stuff, but it needs to be done.