Recently, one of my colleagues invited me to an AWS live stream talk she was giving about building secure GraphQL APIs, using Auth0. She’s been… Read More »Discover secure access for GraphQL APIs: an AWS live-stream
Delegated Authorization
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 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.
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.
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.
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.
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.
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).
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.
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).
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?
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.
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.
With Auth0, Access Tokens are consistently expressed in the self-contained, industry standard, secure JSON Web Token (JWT) format.
Provide additional levels of security on the OAuth 2.0 Refresh Token standard, with Refresh Tokens Rotation provided by Auth0.
Employ Adaptive MFA and deploy fine-tuned Step-Up Authentication using intelligent MFA that dynamically fits customer behaviours. All whilst satisfying your business needs.
Customize identity flows with visual drag-and-drop Actions to build functionality that will address your unique requirements.
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 the Auth0 Blog, and learn more about integrating Authorization within your APIs, leveraging Access Tokens generated by Auth0.
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!
Helpful Identity & Access Management articles that are timely and relevant, whatever your level of experience. Whether you prefer to learn by reading, listening, watching videos, cloning repos, copying code, or attending a workshop or conference: content is everywhere and made for developers like you. Click on the image to subscribe to the newsletter today!
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.
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!
Hi 👋 I’m an Identity and Access Management specialist and ex Principal Developer Advocate at Auth0 by Okta. As an Innovator, Architect, Consultant and Engineer, I have have more than 30 years of experience designing and developing secure and robust software solutions. And when I’m not helping folks with the complexities of Customer Identity, you can usually find me working behind the scenes, acting in or directing a show at my local theatre.