Externalising the Security Token Service and Identity Provider

Modern access control protocols such as OAuth 2.0 and OpenID Connect (OIDC) rely on a security token being passed from client to server with a REST call. Clients obtain a security token from a Security Token Service, or STS for short. OAuth 2.0 and OIDC's authorization server is an example of an STS.
In principle, access control protocols could be implemented at each individual API endpoint. Some frameworks encourage this, but the downside is that functionality is duplicated, making it more difficult to ensure security policies and patches are kept up to date and in sync across all endpoints. Key management also becomes more difficult.
A single, centralised Security Token Service (STS) issuing access tokens for all APIs in an organisation facilitates enforcing access control policies. The STS is a choke point through which all access requests must pass.
Many STS implementations come bundled with an Identity Provider (IdP), but they are logically distinct:
  • the IdP authenticates the user, or client,
  • the STS issues tokens.
Tokens may contain claims about the identity of the user, or client, as is the case for the identity token in OIDC. Access tokens, on the other hand, not necessarily.
Arguments for externalising the STS also apply to the IdP. Moreover, upgrading to stronger authentication protocols becomes easier with authentication-mechanism agnostic API endpoints.
IdPs can be used without STS, e.g. for validating Basic Authentication credentials, but this exposes credentials to the relying party and leads to higher coupling between service and authentication mechanism.

Comments

Popular Posts