The Rise of the API

Today’s rich applications support system expansion at an unprecedented rate. Resource servers, more commonly known as APIs (Application Program Interfaces), do away with many of the development requirements needed to build the more traditional web applications and enable the likes of Mobile Apps, SPAs (Single Page Applications), etc.

Hi, I’m Peter Fernandez, an Innovator, Architect, Consultant, Engineer, and Principal Developer Advocate at Auth0 by Okta. Here, I want to share with you some of my experience building APIs that allow safe, secure and consented access to resources using the Auth0 platform.

Basic Authentication

Basic Authentication is a method whereby an HTTP user agent – e.g. a web browser – can provide explicit UserID and Password credentials when making an API request. Typically encoded as a string, this information is passed in the (HTTP) Authorization header of each API request. Basic Authentication typically requires explicit verification of UserID and/or Password credentials – so it doesn’t work well for the likes of Social or Enterprise Federation authentication scenarios.

API Keys

An API key is typically a unique identifier used to authorize access to an API. Whilst an API Key can be used as part of access based on a user context, they’re typically used to perform authentication and authorization where there is no human interaction at all; an API Key is a fixed credential that is usually context agnostic. This essentially precludes the ability to leverage a context that is user-specific and user-consented, let alone making them fundamentally insecure in cases where public clients, such as Mobile Apps or SPAs, are used.

Delegated Authorization…

Implementing user context authorization using the likes of Basic Authentication or an API Key is problematic for the reasons previously described. The solution to the problem is to use Delegated Authorization. As defined by the OAuth 2.0 protocol, Delegated Authorization delivers what is typically referred to as a Bearer Token. A Bearer Token is a type of secure, dynamically generated security artefact that is based upon a user-specific context, and leverages user authentication typically provided by some (independent) IdP.

….delivered by OAuth 2.0

In OAuth 2.0, a Bearer Token is typically called an Access Token and is generated by an (OAuth 2.0) Authorization Server based on an authenticated user context. What an Access Token token looks like is not specifically defined by the protocol. And whilst OAuth 2.0 is typically easy to manage – requiring minimal configuration – there’s much to understand when it comes to integrating the protocol; despite being an industry standard, there are many workflow options that implementers can omit.

Consent…

The notion of Consent is a fundamental part of the OAuth 2.0 specification, and gives a user the ability to authorize the Scope of operation(s) an application can perform when it’s accessing their resources whilst acting on their behalf.

…vs Scope

Scope is the mechanism in OAuth 2.0 whereby an application defines the access desired. An application can request user consent to one or more scopes, and the Access Token issued will be limited to the scopes granted by the consent provided by the user (typically via some interactive UI).

Third Party…

Arguably, OAuth 2.0 was initially developed to provide Access Tokens – a.k.a. Bearer Tokens – that could be used by applications making calls to APIs developed by third-party vendors. As this allowed applications to access user-specific, third-party resources on behalf of a user, the notion of consent was always a first-class citizen.

…vs First Party

However, as OAuth2.0 gained in popularity, more and more application developers discovered the value of using the protocol for accessing (web-based) APIs that they themselves provided – i.e. first-party APIs provided in support of their own applications – as well as for third-party consumption. This meant that consent was no longer something that necessarily needed to be explicitly provided but instead could be something that was implied (i.e. dependent on what was accessing the API).

Build it yourself?

You could build support in-house, yourself. That’s true. Click on the image to read more about doing just that, and watch the recording of my related webinar here. If your team has the resources, time, capacity, knowledge, and expertise in developing SSO; deploying Attack Protection; leveraging OIDC and/or SAML for Authentication, Social and/or Enterprise Federation; implementing Passwordless and/or MFA, and/or (optionally) OAuth 2.0 for API Authorization – then it’s definitely an option. But what if there was a better way?

Authorized by Auth0…

With Auth0, say hello to a fully featured Authorization Server that provides APIs with the ability to support user resources accessed securely on behalf of a user and with that user’s consent. Starting with Auth0 Universal Login, easily leverage features for user authentication like SSO, Social, Enterprise Federation and MFA before generating Access Tokens using OAuth 2.0.

…using OAuth 2.0

Whether you’re building for B2C, B2B, or some combination, the Auth0 Authorization Server delivers OAuth 2.0 functionality at scale. Via the Authentication API, you can also access OAuth 2.0 workflows, such as Device Authorization Flow – that provide solutions when tackling the more complex use case scenarios involving the use of input-constrained devices. All whilst leveraging the full power of the platform at the same time.

Integrate with ease

With a variety of out-of-box options provided by a wide range of SDKs, you can build an initial integration with Auth0, written in any programming language and supporting any technology stack, in a matter of hours. Click on the image to visit the Auth0 SDK website and discover how to integrate with ease.

Read more about it on the Auth0 Blog

Read the Auth0 Blog, and learn more about integrating Authorization within your APIs, leveraging Access Tokens generated by Auth0.

Want to learn more?

Okta provide a wide-range of courses to help you level-up your skills. Why not click on the logo to see what you can discover with Okta Training today!

Begin the journey…

Sign up here, and create a free Auth0 Tenant to begin your journey. Play with prototyping an integration of your existing code – or develop something new; experience the Okta Customer Identity Cloud, powered by Auth0, in a way that best suits you.

…or try a Demo.

If you’re looking for some inspiration, why not take a look at some of the pre-build demos at demo.okta.com – where you can test-drive sample integrations for both the Okta Customer Identity Cloud and the Okta Workforce Identity Cloud too!