37590801?s=460&v=4

A software engineer who dreams about non-electric sheep and autonomous vehicles and likes to champion security.

Software Engineer

Dan Arias

AAA (Authentication, Authorization, Accounting) helps developers secure web apps by verifying users, controlling access, and tracking actions.

Historically, the AAA framework (Authentication, authorization, and accounting) has been deeply tied to network security, particularly in the context of remote access, VPNs, and network devices. However, AAA is a conceptual framework and not a protocol itself, allowing us to apply it anywhere identity and access matter. Instead of a VPN gateway, you’re securing a web application. Instead of a network admin, it’s a customer buying shoes online. The scale gets bigger, the users are external, and the focus shifts toward balancing security and usability, but the AAA principles still fit to help us build robust, secure, and maintainable user-facing applications.

For developers, considering AAA in your design decisions means not only verifying who your users are (Authentication) but also controlling what they can do (Authorization) and tracking their actions for auditing and analytics (Accounting). This holistic approach minimizes security risks, enhances user experience, and simplifies compliance.

## A Framework to Measure Identity Platforms

A good identity platform gives you features out of the box that tackle each component of the AAA triad, transforming a simple login system into a comprehensive identity management system that meets your security and compliance requirements. User data is one of the most precious and valuable assets we handle as developers. As such, when we make the decision to delegate creating and handling the identity of our users to a third-party vendor, we need to ensure that we are getting better security, scalability, and user-centric experience than what we could build ourselves. The AAA framework is a helpful tool to assess whether an Identity-as-a-Service (IDaaS) vendor can help you build application systems that are resilient against threats, aligned with business requirements, and equipped for future growth.

In today’s competitive digital landscape, including identity and security as part of your MVP or existing product is a competitive advantage. A holistic approach to security is not just an option—it’s a necessity. However, not every player in the field can deliver the security the current security and threat landscape requires. Let’s dive into why Auth0 is a robust identity platform that meets the requirements of the AAA framework and why you should consider it as your identity solution of choice.

## Authentication

Authentication is the process of verifying a user's identity before granting access to your application. It answers the question: **"Who are you?"**

* [Seamless User Sign-Up and Login](https://auth0.com/docs/authenticate/login)
    * Auth0 offers multiple authentication methods, such as social logins, passwordless options, and multi-factor authentication (MFA). These features enable quick and secure identity verification.
* [Personable User Experience](https://auth0.com/docs/customize)
    * With customizable interfaces, Auth0 reduces barriers during sign-up and login, ensuring that the verification process is both secure and user-friendly.
* [Relevant User Journeys](https://auth0.com/docs/customize/forms)
    * Auth0 offers customization of the metadata you collect from users or creates a unique authentication journey that serves your business needs while still being secure.
* [Uncompromised Internationalization and Localization](https://auth0.com/docs/customize/internationalization-and-localization)
    * Auth0 can handle different languages across the authentication experience, allowing you to connect authentically and accurately with millions of potential customers across the globe. Auth0 adapts to your users instead of forcing users to adapt to inflexible platforms.

## Authorization

Authorization defines what actions or resources a user is allowed to access once they are authenticated. It answers the question: **"What can you do?"**

Auth0 allows developers to implement flexible yet comprehensive authorization models that fit different threat models.

* [Role-Based Access Control (RBAC)](https://auth0.com/blog/an-overview-of-commonly-used-access-control-paradigms/#Role-Based-Access-Control--RBAC-):
    * Auth0 allows you to set granular permissions by assigning roles to users. This ensures that users only access the features and data relevant to their privileges.
* [Auth0 Actions](https://auth0.com/docs/manage-users/access-control/sample-use-cases-actions-with-authorization)
    * Actions are secure  Node.js functions that allow you to modify or complement the outcome of the decision made by pre-configured authorization policies. Developers can use Auth0 Actions to[ handle more complicated cases](https://auth0.com/docs/manage-users/access-control/sample-use-cases-actions-with-authorization) than is possible with role-based access control (RBAC).
* [Fine Grained Authorization](https://auth0.com/fine-grained-authorization)
    * Auth0 FGA delivers relationship-based access control ([ReBAC](https://auth0.com/blog/an-overview-of-commonly-used-access-control-paradigms/#Relationship-Based-Access-Control--ReBAC-)) designed for complex authorization needs, such as restricting resource edits to team leads. As a managed service, it scales to handle millions of permission checks per second with minimal latency, eliminating the need to build and maintain custom solutions.

## Accounting

Accounting, also known as auditing, involves tracking and logging user activities within your application. It answers the question: **"What did you do?"**

* [Detailed Logging](https://auth0.com/docs/deploy-monitor/logs)
    * Auth0 maintains a comprehensive audit trail of authentication and authorization events. This detailed logging is essential for monitoring user behavior and identifying potential security incidents.
* [Usage Analytics](https://auth0.com/docs/get-started/auth0-overview/dashboard/activity)
    * The collected data helps analyze user interactions, optimize authentication flows, and ensure compliance with industry regulations. Accounting provides valuable insights into how your application is used.
* [Log Streaming](https://auth0.com/docs/customize/log-streams)
    * Auth0's log streaming service allows you to export tenant log events to a log event analysis service URL, leveraging robust data services, such as DataDog, Splunk, and Amazon EventBridge, and allowing you to react to events like password changes or new registrations with your own business logic.

## Bringing It All Together

Overlaying the AAA framework on your Auth0-powered B2C or B2B solutions ensures:

* **Enhanced Security:**
    * A multi-layered approach that not only verifies identities (Authentication) but also enforces precise access controls (Authorization) and continuously monitors user activities (Accounting).
* **Improved User Experience:**
    * While users benefit from a smooth and secure sign-up process, the detailed authorization rules and accounting measures ensure that they access the right features with confidence.
* **Operational Excellence:**
    * With robust logging and analytics, you can swiftly detect anomalies, refine your application, and maintain compliance with regulatory standards.

If you haven’t tried it already, [get started with Auth0 today](https://a0.to/get-started)!


Authentication, Authorization, and Accounting For Developers

jimena-garbarino

Jimena is an experienced result and value-oriented programmer with a strong engineering background. She excels with Ruby on Rails, Java, and Scrum development. She has worked in web development for 10+ years in many industries and has a master's degree in software engineering from Universidad de Buenos Aires.

Spring Cloud Developer

Jimena Garbarino

Implementing OpenID Connect authentication in Java Web Applications with Okta Spring Boot Starter and Spring Security support for Authorization Code Flow with PKCE

Proof Key for Code Exchange (PKCE) in Web Applications with Spring Security

andrea-chiarelli

I have over 20 years of experience as a software engineer and technical author. Throughout my career, I've used several programming languages and technologies for the projects I was involved in, ranging from C# to JavaScript, ASP.NET to Node.js, Angular to React, SOAP to REST APIs, etc.

In the last few years, I've been focusing on simplifying the developer experience with Identity and related topics, especially in the .NET ecosystem.

Principal Developer Advocate

Andrea Chiarelli

Let’s find out how to add Auth0 authentication to the new Blazor application model introduced in .NET 8.

Add Auth0 Authentication to Blazor Web Apps

Pradheepa Pullanieswaran

Pradheepa Pullanieswaran is a Developer Advocate at Okta, with a real love for backend and open-source technologies. She has worked in enterprise and web technologies for over a decade and now on the journey of helping developers to better secure their application. She is also an active member of Women Who Code and mentors women to step into the software industry. She loves to read and spends time with her family in her spare time.

Staff Developer Advocate

Web Authentication API (WebAuthn) is a W3C and FIDO specification that allows registration and authentication of users using public key cryptography instead of a password.

## Introduction

WebAuthn (Web Authentication) is an API specification by W3C that facilitates a secure way for users to log in to online services and websites using various authentication methods, such as biometrics (e.g., fingerprint or facial recognition) and hardware-based authenticators (e.g., USB or NFC tokens). 

## Key Features of WebAuthn

### Phishing resistant

WebAuthn uses [public key cryptography](https://auth0.com/blog/how-to-explain-public-key-cryptography-digital-signatures-to-anyone/); the user's private key never leaves their device. Since WebAuthn relies on cryptographic keys, it is resistant to phishing attacks. Assuming that a bad actor tricks the user into entering their credentials on a phishing site, the attacker cannot use those credentials because they are scoped to a specific domain. In short, a credential created for `webauthn.me` cannot be used by a fake website, `webauth.me`. According to [Verizon DBIR 2023](https://www.verizon.com/business/resources/reports/2023-data-breach-investigations-report-dbir.pdf), Phishing is one of the major attacks on a web-based application, as shown in the following image. Using WebAuthn, the web applications could have easily averted these attacks. 
   
#### Action varieties in Social Engineering incidents

![Action varieties in Social Engineering incidents](https://images.ctfassets.net/23aumh6u8s0i/EAHiNaQrRaclMm2OnR1TA/cc50a06eef6af456d6a02f74731d4f6e/Phishing_DBIR.png)
 
### High-Security standards 

WebAuthn leverages industry-standard cryptographic algorithms and protocols to ensure the highest level of security. It utilizes the [authenticators](https://auth0.com/blog/not-all-mfa-is-created-equal/#Factors--Authenticators--and-Assurance) to confirm the user's identity and create highly secure public-private key credentials. There are two types of authenticators: roaming authenticators, like hardware security keys, and platform authenticators, like your laptop or device, that support biometrics, such as fingerprint recognition, facial recognition, and voice recognition, depending on the capabilities of the user's device.

### Seamless user experience

With WebAuthn, users can authenticate with a single gesture or action, providing a convenient and frictionless login experience. While delivering a seamless and convenient authentication experience for users, it also enhances security.

## WebAuthn Roles

**Relying Party** - This is the website or online service the user wants to access. The relying party initiates the WebAuthn authentication process and verifies the user's identity.

**WebAuthn Client Device** -  The user's device (e.g., smartphone, computer) that supports WebAuthn and communicates with the relying party. It is capable of hosting the private keypair in secret storage that a user can access through biometrics or PIN.

**User** -  The individual attempting to access a relying party's website or services.

**Authenticator** - There are two types of authenticators, i.e., Platform Authenticators and Roaming Authenticators. 
  
Platform Authenticators refer to a specific type of authenticator built into the user's device or platform, such as a smartphone, laptop, or desktop computer. For example, a smartphone's fingerprint sensor or a laptop's built-in biometric recognition system can act as a platform authenticator. 
  
Roaming Authenticators are authenticators not tied to any particular platform but can be used to authenticate across multiple devices. They are also sometimes referred to as cross-platform or external authenticators. e.g., hardware security keys like the YubiKey.

<include src="WebAuthnMeCTA" group="A"/>

## How WebAuthn Works

WebAuthn's mode of authentication consists of a Registration Flow and an Authentication Flow. With WebAuthn, there are no longer shared credentials between the user and the relying party. A public-private key pair is generated with the help of the authenticators and is used instead of the password. Let us look into the user journey of the registration and authentication flows.

### Registration flow

#### A User visits a website

The process begins when a user visits a website or a web application that supports WebAuthn for authentication and requests the website to create a new account.

#### Initiating registration

The website, often called the relying party, begins the registration process. It generates a unique and cryptographically random challenge and communicates to the user's browser that it wants to register a new public-private key pair for the user.

#### The User chooses an authenticator to generate a public-private key pair

The user selects their preferred authenticator, a platform authenticator (built into their device, e.g., fingerprint sensor), or an external authenticator (e.g., a hardware security key). The chosen authenticator generates a new public-private key pair for the user and signs the challenge generated by the relying party with those keys. 

#### The Authenticator sends back the user credentials

The private key is securely stored within the authenticator, while the public key is sent back to the website along with the signed challenge and an optional private key ID.

#### The Website stores the user credential

The website stores the user's public key and the private key ID (if sent) and associates it with the user's account for future authentication; 

![WebAuthn Registration Flow](https://images.ctfassets.net/23aumh6u8s0i/6tOAUn8BVSqRrvnoe9fekn/d4614b12e493faeefc6d3cfaf36f3245/WebAuthn_Registration_Flow.png) 

The registration process is completed, and no more shared secrets are exchanged over the network between the user and the server, eventually reducing the risk of stolen credentials.

### Authentication flow

Once the user's registration is complete, the returning user can verify the credentials and log in to the application. Following are the steps that take place in the authentication flow for the user.

#### User returns to the website 
When users return to the website to access the protected resources, the web application prompts the user to authenticate. The user provides the username to the server.

#### Website generates an authentication challenge
The website generates a new challenge and sends it to the user's browser.

#### User requests authenticator to sign the challenge
The user selects the authenticator they used during registration, or the authenticator may be automatically detected and requested to sign the challenge. 

#### Authenticator signs the challenge
The authenticator signs the challenge using the private key stored during the registration flow. The authenticator sends the signed response and the public key back to the website.

#### User verification
The website receives the signed response and the user's public key. It verifies the response by checking the signature against the stored public key. If the verification is successful, the website grants the user access to the requested resources.

![Authentication Flow](https://images.ctfassets.net/23aumh6u8s0i/5gbfSpwf2b3EOAP4gP1elm/ae3db34de58eca086f963d06303c54cb/WebAuthn_Authentication_Flow.png)

The user is authenticated securely without a password and with less friction to the user.

## How to Implement the WebAuthn API

Two methods in the WebAuthn API mediate between the user and the server to create the public-private key pair.

1. `navigator.credentials.create`
2. `navigator.credentials.get`

### Using the "navigator.credentials.create" method

The `navigator.credentials.create` method is used to initiate registering a new credential for a user. This method allows users to create a new credential, such as a public-private key pair, which can be used for secure authentication in the future. Here's how you can use `navigator.credentials.create`.

#### Prepare credential creation options
You need to define the options for the credential creation request. These options specify various credential creation parameters, such as the relying party ID (your website's domain), user information, and allowed authenticator types (e.g., platform authenticator or external security key).

Here's an example of how to create credential creation options:

```
const publicKey = {
  challenge: new Uint8Array(/* Generate a random challenge */),
  rp: {
    name: 'Webauthn Me', // Relying party name
    id: 'webauthn.me',     // Relying on party ID
  },
  user: {
    id: new Uint8Array(/* Generate a unique user ID */),
    name: 'jane.doe@example.com',
    displayName: 'Jane Doe',
  },
  pubKeyCredParams: [
    { type: 'public-key', alg: -7 }, // ES256 algorithm
  ],
  timeout: 60000, // 1-minute timeout
  attestation: 'direct', // Attestation type
};

```

The following section describes each variable in detail.

- `challenge`: A challenge is a random value generated by the server and included in the registration request that helps to prevent replay attacks. The challenge serves as a nonce (number used once), ensuring that each registration request is fresh and not subject to replay. It prevents attackers from intercepting and reusing a valid registration message to gain unauthorized access. The server should validate the response promptly and reject it if the challenge has expired or does not match.
- `rp`: The relying party is the entity that relies on WebAuthn for authentication. For example, it is the domain of the website that implements WebAuthn to enable secure user authentication. Validating the relying party information helps prevent phishing attacks.
- `user`: Information about the user who wants to register.
- `pubKeyCredParams`: It is an array that specifies the acceptable public key algorithms and parameters for the generated credential. The array consists of two properties,
    1. `type`: A string indicating the cryptographic algorithm to be used. Common values include "public-key" for ECDSA (Elliptic Curve Digital Signature Algorithm) or "rsa" for RSA (Rivest–Shamir–Adleman)
    2. `alg`: An integer representing the specific algorithm within the given type. For example,`-7`representing ES256 for ECDSA with SHA-256.
- `timeout`: The time limit for the credential creation process.
- `attestation`: The attestation parameter specifies how the authenticator (e.g., security key, biometric device) should attest to the authenticity of the public key credential it generates during the registration process. The attestation parameter can take different values, each representing a different attestation type. Common values include:
    1. `none`: No attestation is requested. The authenticator generates a credential without any assertion of its authenticity. This is suitable for scenarios where the relying party already has a secure means of verifying the authenticator.
    2. `direct`: The authenticator provides an attestation statement, but the format and content depend on the authenticator type. This is also known as "self-attestation."
    3. `indirect`: The authenticator forwards an attestation statement obtained from a third-party service, typically the manufacturer or a trusted party.

#### Call "navigator.credentials.create"
Use the `navigator.credentials.create` method to initiate the credential creation process.

```
navigator.credentials.create({ publicKey })
  .then((credential) => {
    // Handle the successful credential creation
    // Send the credential information to your server for storage
  })
  .catch((error) => {
    // Handle any errors that occurred during credential creation
  });

```
`publicKey`:  It is the variable defined in the previous step. 

#### Handle the Credential Creation Response
If the user successfully creates a credential, the `navigator.credentials.create` promise will resolve with a credential object. You should send this credential object to your server for storage and associate it with the user's account.

```
// Handle the successful credential creation
// Send the credential information to your server for storage
navigator.credentials.create({ publicKey })
  .then((credential) => {
    // Response object has information about the authenticator data, 
    // public key, transport mechanisms, and more.
    const response = credential.response;

    // Access attestationObject ArrayBuffer
    const attestationObj = response.attestationObject;

    // Access client JSON
    const clientJSON = response.clientDataJSON;

    // Return authenticator data ArrayBuffer
    const authenticatorData = response.getAuthenticatorData();

    // Return public key ArrayBuffer
    const pk = response.getPublicKey();

    // Return public key algorithm identifier
    const pkAlgo = response.getPublicKeyAlgorithm();

    // Return permissible transports array
    const transports = response.getTransports();
    
    // Send the credential information to the server for storage
    return credential;
  })
  .catch((error) => {
    // Handle any errors that occurred during credential creation
    console.log('FAIL', error)
  });


```

If the credential creation fails or if there are errors, the promise will be rejected, and you can handle the errors accordingly.

Remember that the server-side storage and management of user credentials are essential for the WebAuthn authentication process. The server should securely store the user's public key and other relevant information to enable future authentication.

### Using the "navigator.credentials.get" method

The `navigator.credentials.get` method is part of the WebAuthn API and is used to initiate the process of authenticating a user based on the credentials they have previously registered. This method is typically used in conjunction with the `navigator.credentials.create` method for credential registration. Here's how you can use this method.

#### Prepare authentication options
You need to define the options for the authentication request. These options specify the criteria for the user's credentials for authentication. You can include the relying party ID (e.g., your website's domain) and specify the allowed authentication methods.

Here's an example of how to create authentication options:

```
const publicKey = {
  challenge: new Uint8Array(/* Generate a random challenge */),
  rpId: 'webauthn.me', // Relying party ID
  allowCredentials: [
    {
      type: 'public-key',
      id: /* The credential ID of the user's registered credential */,
    },
  ],
  userVerification: 'preferred', // or 'required'
};
```

The following section describes each variable in detail.

- `userVerification:` It specifies the preferred user verification method that the relying party wishes to be performed during the WebAuthn authentication process. The [userVerification parameter](https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Guide/User_Presence_vs_User_Verification.html) can take different values, each representing a different user verification method. Common values include `required`, `preferred`, and `discouraged.`
- `allowCredentials:` It is an array that contains one or more "PublicKeyCredential" objects representing the credentials that the relying party is willing to accept during the authentication process. Each element in the allowCredentials array is an object with the following properties: 
  1. `type`: A string specifying the type of the credential. Commonly, this is set to "public-key".
  2. `id`: A byte array representing the credential ID. This corresponds to a credential that was previously created during the registration process.
- `challenge` and  `rpId` are the same parameters used for the `navigator.credentials.create` method.

#### Call "navigator.credentials.get"

Use the `navigator.credentials.get` method to initiate the authentication process:

```
navigator.credentials.get({ publicKey })
  .then((assertion) => {
    // Handle the successful authentication assertion
  })
  .catch((error) => {
    // Handle any errors that occurred during authentication
  });
```

`publicKey`:  It is the variable defined in the previous step.

#### Handle the authentication response
If the user successfully authenticates, the `navigator.credentials.get` promise will resolve with an authentication assertion containing information about the user's successful authentication. You can then send this assertion to your server for verification.

```
// Handle the successful authentication assertion
// Send the assertion to your server for verification
navigator.credentials.get({ publicKey })
  .then((assertion) => {
    // Handle the successful authentication assertion
    // The assertion response has information about the authenticator data, 
    // signature, and user handle
     const response = assertion.response;

    // Access authenticator data ArrayBuffer
    const authenticatorData = response.authenticatorData;

    // Access client JSON
    const clientJSON = response.clientDataJSON;

    // Access signature ArrayBuffer
    const signature = response.signature;

    // Access userHandle ArrayBuffer
    const userHandle = response.userHandle;

    return assertion;
  }).catch((error) => {
    // Handle any errors that occurred during authentication
    console.log('FAIL', error)
  });
```

If the authentication fails or if there are errors, the promise will be rejected, and you can handle the errors accordingly.

Remember that the server-side verification of the authentication assertion is an essential part of the process. The server should validate the assertion's signature and ensure that it matches a previously registered credential for the user.

These steps provide a high-level overview of how to use `navigator.credentials.create` and `navigator.credentials.get` in the WebAuthn API for user authentication. The actual implementation will vary based on your specific use case and server-side verification requirements.

## Conclusion

WebAuthn offers a passwordless and highly secure alternative to traditional authentication methods. Leveraging public key cryptography, user verification methods like biometrics, and a challenge-response model, WebAuthn effectively mitigates the risks associated with phishing attacks and enhances online security. It's important to note that while WebAuthn is phishing-resistant, it is not immune to all types of attacks. Therefore, proper implementation and security best practices on both the client and server sides are crucial to harness the security benefits of WebAuthn fully. [Auth0 supports WebAuthn](https://auth0.com/blog/mfa-with-webauthn-for-fido-device-biometrics-now-available/) and adheres to industry best practices and security standards, removing the heavy lifting of implementing on your own. It is a simple toggle switch in the configuration to show up in your login box, and all the background processing is taken care of by Auth0.

<include src="SignupCTA" text="Try out WebAuthn with Auth0?" linkText="Get started →" />

WebAuthn - A Short Introduction

001c9ddc5ceb9829b6aaf24f5d28502a

I am software developer with a keen interest in open-source technologies, Linux, and native development. I've worked on many different platforms Android, iOS, Win32, Linux, FreeRTOS, the Web, and others. I've gone through the whole stack and I enjoy learning and using the latest technologies. I now work as a full-stack developer at Auth0.

Senior Engineer

Sebastian Peyrott

In this post you will learn about Single Sign-On (SSO) authentication and how to use it for your web apps

[Single Sign-On (SSO)](https://auth0.com/resources/whitepapers/definitive-guide-to-single-sign-on) authentication is now required more than ever. Nowadays, almost every website requires some form of authentication to access its features and content. With the number of websites and services rising, a centralized login system has become a necessity. In this post, we will study how **SSO authentication** is implemented for the web. Read on!

<AmpContent>
<amp-youtube
    data-videoid="Vp6kx4Sd_E0"
    layout="responsive"
    width="480" height="270">
</amp-youtube>
</AmpContent>
<NonAmpContent>
<div class='embed-container' style="position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden; max-width: 100%;margin-bottom:40px;"><iframe style="position: absolute; top: 0; left: 0; width: 100%; height: 100%;" src='https://www.youtube.com/embed/Vp6kx4Sd_E0' frameborder='0' allowfullscreen></iframe></div>
</NonAmpContent>

## Federated Identity Glossary

The concept of a centralized or linked electronic identity is known as *federated identity*. Federated identity systems handle several concerns:

- Authentication
- Authorization
- User attributes exchange
- User management

The **authentication** aspect deals with validating user credentials and establishing the identity of the user.

**Authorization** is related to access restrictions (e.g., is the user allowed to access X resource?). 

The **attributes exchange** aspect deals with data sharing across different user management systems. For instance, fields such as *"real name"* may be present in multiple systems. A federated identity system prevents data duplication by linking the related attributes. 

Lastly, **user management** is related to the administration (creation, deletion, update) of user accounts. A federated identity system usually provides the means for administrators (or users) to handle accounts across domains or subsystems.

SSO is strictly related to the **authentication** part of a federated identity system. Its only concern is establishing the identity of the user and then sharing that information with each subsystem that requires the data. Below, we focus on this crucial aspect of a federated identity system.

![What is single sign-on separator 1](https://images.ctfassets.net/23aumh6u8s0i/2xIzg7UIbBpGNvCeRsdn4k/32f29b73fc2b4bd33bac6fe124d9bfb1/what-is-sso-1)

## Single Sign-On (SSO) Authentication

Sooner or later web development teams face one problem: you have developed an application at domain X and now you want your new deployment at domain Y to use the same login information as the other domain. In fact, you want more: you want users who are **already logged-in** at domain X to be already logged-in at domain Y. This is what SSO is all about.

![Non-Single-Sign-On Scenario](https://images.ctfassets.net/23aumh6u8s0i/4pa532TumNn6TI3gQmMWEw/0a6182b447b75b24bea1b763c1ba73a1/non-sso-scenario)

The obvious solution to this problem is to **share session information** across different domains. However, for security reasons, browsers enforce a policy known as the [*same origin policy*](https://en.wikipedia.org/wiki/Same-origin_policy). This policy dictates that cookies (and other locally stored data) can **only be accessed by its creator** (i.e. the domain that originally requested the data to be stored). In other words, domain X cannot access cookies from domain Y or vice versa. This is what SSO solutions solve in one way or the other: sharing session information across different domains.

![No cookie sharing](https://images.ctfassets.net/23aumh6u8s0i/2WJQLWBpByFyth3ufF3Af0/5f341d8816d77f20dc05c5a2f31ec89f/same-origin-policy-forbids-this)

Different SSO protocols share session information in different ways, but the essential concept is the same: there is a **central domain**, through which authentication is performed, and then the **session is shared** with other domains in some way. 

For instance, the central domain may generate a signed [JSON Web Token (JWT)](https://auth0.com/docs/jwt), which may be encrypted using [JSON Web Encryption (JWE)](https://tools.ietf.org/html/rfc7516). This token may then be passed to the client and used by the authentication domain as well as any other domains. The token can be passed to the original domain by a redirect and it contains all the information needed to identify the user for the domain requiring authentication. As the token is signed, it cannot be modified in any way by the client.

![SSO - Central authentication domain](https://images.ctfassets.net/23aumh6u8s0i/2GrAhJRypY1XQx3TIDbqzO/ecbd47c21f1e1c1fd334a239b9015a08/using-central-auth-domain)

Whenever users go to a domain that requires authentication, they are **redirected** to the authentication domain. As users are **already logged-in** at that domain, they can be immediately redirected to the original domain with the necessary authentication token.

![Single Sign-On Authentication](https://images.ctfassets.net/23aumh6u8s0i/4hakDPwQtaPfcDNwkd4C9x/e54ee76304953540b4b71fcccbaf690a/typical-sso-v2)


## SSO Authentication with Auth0

If you have been reading about SSO online, you have probably found that there are many different implementations: OpenID Connect, Facebook Connect, SAML, Microsoft Account (formerly known as Passport), etc. Our advice is to choose whatever is simplest for your development efforts. For instance, [SAML](https://auth0.com/docs/protocols/saml) is deeply entrenched in enterprise developments, so in some cases, it will make sense to pick that. If you think you will need to integrate your development with more than one alternative, don't despair: there are frameworks that allow interoperability between different SSO solutions. In fact, that's one of the things we do at Auth0.

<include src="SignupCTA" text="Try out Auth0 authentication for free." linkText="Get started →" />

You can go and check our [docs on Single Sign-On](https://auth0.com/docs/sso/single-sign-on) and the [Auth0 SSO samples](https://github.com/auth0/auth0-sso-sample).

If you remember the Typical SSO Scenario diagram we saw earlier, you can see how Auth0 comes to play in the next diagram:

![SSO with Auth0](https://images.ctfassets.net/23aumh6u8s0i/5n5APnJDhCtUiyZvyAG6rK/5a9faf400e436dd131bdee21b81c8761/auth0)

In this case, **Auth0 is the [Authentication Server](https://auth0.com/blog/what-is-an-authentication-server/)** and it works as a *bridge* between different SSO frameworks. 

<include src="ebook-ads/SsoGuide" />

## Conclusion

Single Sign-On authentication is here to stay. Decentralized systems are becoming more and more common and authentication is an essential aspect of all of them. SSO solves a big problem: how to manage the increasing number of users across a whole ecosystem of applications and services. Frameworks such as [OpenID Connect](https://auth0.com/resources/ebooks/the-openid-connect-handbook?ref=blog) and services such as the one we provide at Auth0 make [integrating Single Sign-On](https://auth0.com/learn/how-to-implement-single-sign-on/) into your new or existing applications much easier. If you are implementing authentication for a new application or service, consider integrating SSO from the get-go.

![What is single sign-on separator 3](https://images.ctfassets.net/23aumh6u8s0i/5L0CZk6C2On5CTXSHlE3MF/50e145cd648e88dd800f90ca19cfa1e4/what-is-sso-3)

What Is Single Sign-On Authentication (SSO) And How Does It Work?

matt-raible

Matt Raible is a well-known figure in the Java community and has been building web applications for most of his adult life. For over 20 years, he has helped developers learn and adopt open source frameworks and use them effectively. He's a web developer, Java Champion, and Developer Advocate at Okta. Matt is a frequent contributor to open source and a big fan of Java, IntelliJ, TypeScript, Angular, and Spring Boot. 

Developer Advocate

Matt Raible

Use JHipster to build a photo-sharing app for web and mobile that has a React front-end with OIDC authentication and a Spring Boot back-end with OAuth2 authorization.

Integrate React Native and Spring Boot Securely

Learn how to build client-side Web apps using Blazor and how to secure them with Auth0.

What is Blazor? A Tutorial on Building Web Apps with Authentication

Learn how to secure an ASP.NET Core Web API by granting access only to authorized users through Auth0 authentication and authorization services.

Having control over who can access your API is a necessary requirement to make your application secure. This article will show you how to restrict access to your ASP.NET Core Web API to authorized users only.

## Setting up the Web API Application

Let's start by setting up the ASP.NET Core Web API application to be protected. You can download a glossary Web API from [this GitHub repository](https://github.com/auth0-blog/glossary-web-api-aspnet/tree/starter) by running the following command in a terminal window:

```bash
git clone --branch starter --single-branch https://github.com/auth0-blog/glossary-web-api-aspnet.git

```

This ASP.NET application provides you with a CRUD Web API to manage a glossary of terms. You can learn the details of its implementation by reading [this article](https://auth0.com/blog/building-aspnet-web-api).

Once you download the application, move to the `glossary-web-api-aspnet` folder and launch it by typing `dotnet run` in a terminal window. By pointing your browser to `https://localhost:5001/swagger`, you should see a page like the following to interactively test the APIs:

![Swagger UI for Web API](https://images.ctfassets.net/23aumh6u8s0i/39X3FZbdleAybhhvH5hCV7/b0276f9319a0a8110fcffc1dd583f602/webapi-swagger-ui.png)

The Web API application allows you to get a list of term definitions or a single term definition. It also lets you create a new definition and modify or delete an existing one.

The current implementation of this glossary Web API allows anyone to perform all the available operations on the glossary. Most probably, you want to allow everyone to get a single glossary item or the full glossary. Still, only authorized users should be enabled to create, update, and delete glossary items.

Let's go and see how to protect these three actions by integrating your ASP.NET Core Web API with [Auth0](https://auth0.com) services.

## Registering the Web API with Auth0

To start securing your API with Auth0, you need an Auth0 account. If you haven't got one, you can <a href="https://a0.to/blog_signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">sign up for a free one</a>. Now, you can register your Web API through the [Auth0 Dashboard](https://manage.auth0.com/).  Move to the [API section of the Dashboard](https://manage.auth0.com/#/apis) and follow these steps:

1. Click on *Create API*
2. Provide a friendly name for your API (for example, *Glossary API*) and a unique identifier in the URL format (for example, *https://glossary.com*)
3. Leave the signing algorithm as RS256 and click the *Create* button

These steps make Auth0 aware of your Web API and will allow you to control access.

> **Note**: While you are in the Auth0 Dashboard, take note of your Auth0 domain. You will need it soon. This is a string in the form `YOUR-TENANT-NAME.auth0.com` where `YOUR-TENANT-NAME` is the name you provided when you created your account with Auth0. For more information, [check the documentation](https://auth0.com/docs/getting-started/the-basics#domains).

<details>
  <summary>Using the Auth0 CLI</summary>
As an alternative to the Dashboard, you can use [the Auth0 CLI](https://auth0.com/blog/introducing-auth0-cli/) to register your API with Auth0.


In this case, [install the CLI on your machine](https://github.com/auth0/auth0-cli#installation) and [configure it to access your Auth0 tenant](https://github.com/auth0/auth0-cli#login). Then, run the following command in a terminal window:

```bash
auth0 apis create --name "Glossary API" --identifier https://glossary.com --scopes ""
```

This command creates an entry for your API with the name *Glossary API* and the unique identifier `https://glossary.com`. You are not specifying any [scope](https://auth0.com/docs/scopes) for this application right now.

Running this command has exactly the same effect as registering your API through the Auth0 Dashboard.

After the registration, you will get an output like the following:

```bash
=== <YOUR_AUTH0_DOMAIN> API created

  ID          60ac3b89f0cd4a003d42e850  
  NAME        Glossary API              
  IDENTIFIER  https://glossary.com   
  SCOPES  
```

Take note of the values for the `<YOUR_AUTH0_DOMAIN>` placeholder and the identifier.
</details>

## Enabling Authorization Support

The next step is to adapt the ASP.NET Core Web API application's code to use Auth0 authorization services.

### Configuring the Web API

Back in your ASP.NET application, open the `appsettings.json` configuration file and replace its content with the following:

```json
{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  },
  "AllowedHosts": "*",
  "Auth0": {
    "Domain": "YOUR_AUTH0_DOMAIN",
    "Audience": "YOUR_UNIQUE_IDENTIFIER"
  }
}
```

Replace the `YOUR_AUTH0_DOMAIN` placeholder with your Auth0 domain and the `YOUR_UNIQUE_IDENTIFIER` placeholder with the value you provided as a unique identifier of your API (`https://glossary.com`, if you kept the value suggested above).

### Integrating with Auth0

In order to interact with the Auth0 authorization services, your application needs to be able to handle tokens in the [JWT](https://jwt.io/) (*JSON Web Token*) format. You can accomplish this by installing the `Microsoft.AspNetCore.Authentication.JwtBearer` library. Move to your application folder and type the following command in a terminal window:

```bash
dotnet add package Microsoft.AspNetCore.Authentication.JwtBearer
```

When the installation is complete, open the `Startup.cs` file and add the `JwtBearer` namespace. The `using` section of the file should look as shown below:

```c#
//Startup.cs
...existing code... 
using Microsoft.OpenApi.Models;
using Microsoft.AspNetCore.Authentication.JwtBearer; //👈 new code

namespace Glossary
{
  //...existing code...
}
```

In the same file, replace the `ConfigureServices()` method of the `Startup` class with the following code:

```c#
//Startup.cs

// ...existing code...
    public void ConfigureServices(IServiceCollection services)
    {
      //👇 new code
      services.AddAuthentication(options =>
      {
        options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
        options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
      }).AddJwtBearer(options =>
      {
        options.Authority = $"https://{Configuration["Auth0:Domain"]}/";
        options.TokenValidationParameters = 
          new Microsoft.IdentityModel.Tokens.TokenValidationParameters
          {
            ValidAudience = Configuration["Auth0:Audience"],
            ValidIssuer = $"{Configuration["Auth0:Domain"]}",
            ValidateLifetime = true,
          };
      });
      //👆 new code

      services.AddControllers();
      services.AddSwaggerGen(c =>
      {
        c.SwaggerDoc("v1", new OpenApiInfo { Title = "Glossary", Version = "v1" });
      });
    }
// ...existing code...
```

You added the authentication service by specifying the JWT bearer scheme. You also configured the JWT handler by using the domain and audience values from the `appsettings.json` configuration file. In particular, you built the authority URL based on the Auth0 domain and set the parameters that allow the access token to be validated. Specifically, a token is considered valid if it meets the following criteria:

- it has the expected audience,
- it was issued by the expected domain,
- it is not expired.

Finally, replace the `Configure()` method of the `Startup` class with the following code:

```c#
//Startup.cs

// ...existing code...
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }

    app.UseHttpsRedirection();
    app.UseRouting();
  
    app.UseAuthentication();  //👈 new code
    app.UseAuthorization();
  
    app.UseEndpoints(endpoints =>
    {
        endpoints.MapControllers();
    });
}
// ...existing code...
```

Compared to the previous version, you just added the `app.UseAuthentication()` statement to enable authentication for your application.

<details>
  <summary>Why do you need authentication?</summary>
You may wonder why you need to register the authentication middleware in your ASP.NET Web API. After all, you should only manage authorization. The authentication middleware is needed because it is responsible for creating the security context under which the code is running.


Also, the registration order is important: you need to register the authentication middleware before the authorization middleware.

For more details, check out the [ASP.NET Web API authentication and authorization documentation](https://docs.microsoft.com/en-us/aspnet/web-api/overview/security/authentication-and-authorization-in-aspnet-web-api).
</details>

<include src="Auth0TemplatesForDotnetCTA" />

## Securing the API Endpoints

Almost everything is ready to secure your application. You just need to protect the actions that allow clients to create, update, and delete glossary items. So, open the `GlossaryController.cs` file in the `Controllers` folder and add the `Microsoft.AspNetCore.Authorization` namespace. The `using` section of the file will look like the following:

```c#
//Controllers/GlossaryController.cs
using System;
using System.Collections.Generic;
using Microsoft.AspNetCore.Mvc;
using System.IO;
using Microsoft.AspNetCore.Authorization;  //👈 new code

namespace Glossary.Controllers
{
  // ...existing code...
}
```

Now, add the `Authorize` attribute to the `Post()`, `Put()`, and `Delete()` methods. As an example, your `Delete()` method should become like shown below:

```c#
//Controllers/GlossaryController.cs
// ...existing code...
        [HttpDelete]
        [Route("{term}")]
        [Authorize]  //👈 new code
        public ActionResult Delete(string term)
        {
            var glossaryItem = Glossary.Find(item =>
                   item.Term.Equals(term, StringComparison.InvariantCultureIgnoreCase));

            if (glossaryItem == null)
            {
                return NotFound();
            }
            else
            {
                Glossary.Remove(glossaryItem);
                return NoContent();
            }
        }
// ...existing code...
```

As you can see, the only difference is the `Authorize` attribute.

> **Note**: You may be wondering if the order of the attributes applied to a method or to a controller class matters. Their order is internally defined, and it depends on the stage of the HTTP pipeline they are bound to and on their scope (global, class, or method scope). So, from a syntactical point of view, it doesn't matter if you put, for example, the `Authorize` attribute before or after the `Route` one.
> For more information on this point, check the [official documentation](https://docs.microsoft.com/en-us/aspnet/core/mvc/controllers/filters?view=aspnetcore-3.0).

<include src="ebook-ads/dotnetIdentity" />

## Testing the Secure Web API

In order to ensure that all works as expected, run the application, point your browser to [https://localhost:5001/swagger](https://localhost:5001/swagger), and test the GET action on the `api/Glossary` endpoint. You should get the list of term definitions as before.

### Testing unauthorized accesses

Now, try to add a new item to the glossary by using the POST action on the `api/Glossary` endpoint as shown in the following picture:

![Calling HTTP POST on the Glossary Web API](https://images.ctfassets.net/23aumh6u8s0i/2Wj5qH5QGMcZC82KC47HVM/758a0589e4254ff6a013deb48808cba7/post-webapi-swagger-ui.png)

This time you should get a `401 Unauthorized` HTTP status code, as shown below:

![Unauthorized response from the Web API](https://images.ctfassets.net/23aumh6u8s0i/4GB1MoOEZ3VoKRddc5Vwxi/0510cf8164263b15d188fc5ab5751424/unauthorized-response.png)

This means that your endpoint is protected: only authorized users can add a new definition to the list. So, in order to add a new item to the glossary, you need to get an access token from Auth0 and make a request to the API endpoint using the [Bearer Authorization scheme](https://www.rfc-editor.org/rfc/rfc6750.html).

### Testing authorized accesses

However, before going ahead, you need a way to provide your access token to the interactive web API documentation. To achieve this goal, edit the `Startup.cs` file and apply the changes shown in the following code snippet to the `ConfigureServices()` method:

```csharp
//Startup.cs
// ...existing code...
    public void ConfigureServices(IServiceCollection services)
    {

      // ...existing code...
      services.AddControllers();

      services.AddSwaggerGen(c =>
      {
        c.SwaggerDoc("v1", new OpenApiInfo { Title = "MyProject", Version = "v1.0.0" });

        //👇 new code
        var securitySchema = new OpenApiSecurityScheme
        {
          Description = "Using the Authorization header with the Bearer scheme.",
          Name = "Authorization",
          In = ParameterLocation.Header,
          Type = SecuritySchemeType.Http,
          Scheme = "bearer",
          Reference = new OpenApiReference
          {
            Type = ReferenceType.SecurityScheme,
            Id = "Bearer"
          }
        };

        c.AddSecurityDefinition("Bearer", securitySchema);

        c.AddSecurityRequirement(new OpenApiSecurityRequirement
          {
              { securitySchema, new[] { "Bearer" } }
          });
        //👆 new code
      });
    }
// ...existing code...
```

You added a few additional configuration options to your API's Swagger instance. In particular, you defined a security schema and added it to the generated documentation as a security requirement.

Now, restart your ASP.NET Core Web API and take a look at the web page shown at the address [https://localhost:5001/swagger](https://localhost:5001/swagger):

![Protected Web APIs in Swagger UI](https://images.ctfassets.net/23aumh6u8s0i/1rNBChKdbCr9fKdpbbYcKR/014f6ace0411febc726959cd88ed8e6a/protected-swagger-ui-webapi.png)

You see the new *Authorize* button and the lock icon on each action. You can configure Swagger to get a more accurate UI, but this topic is out of the scope of this article. Please check out [the official documentation for more details](https://github.com/domaindrivendev/Swashbuckle.AspNetCore#add-security-definitions-and-requirements).

At this point, let's get the access token from Auth0. The simplest way is to access [the API section of your Auth0 Dashboard](https://manage.auth0.com/#/apis) again, select the API that you created before and select the *Test* tab. In this section, you can get a temporary token to test your Web API by clicking the *Copy Token* icon as shown in the following picture:

![Copying temporary token from the Auth0 Dashboard](https://images.ctfassets.net/23aumh6u8s0i/1FENUfKNw5FrmexhvdWwv5/bb1c283a019dc0fd7322e357efd1bdb2/copy-token.png)

Now, head back to your browser and click the *Authorize* button. A window dialog opens, as shown in the following picture:

![Configure access token for Swagger UI](https://images.ctfassets.net/23aumh6u8s0i/18f9kh3tBXiOMbxjSA7j1k/c0ab1d1475b75ef51a50a1009ea3c5c1/access-token-swagger-ui.png)

Paste the token you copied from the Auth0 Dashboard into the text box and click *Authorize*.

With this step, you have configured the interactive documentation to add the Authorization header to each HTTP request. That header's value will be the access token in the form of a bearer token.

If you try to add a new glossary term through the POST action, you should get a successful `201 Created` HTTP status code as before securing the API. The following picture shows an example of such a response:

![A successful response from the protected Web API](https://images.ctfassets.net/23aumh6u8s0i/2iY4mvFFAZGrDcpXKZiFPU/b0f0b3d576e9d0fc19e7fc7574e089a3/success-response-webapi-post.png)

Now your Web API is ready to be securely consumed by clients.

## Recap

This article showed you how to protect your ASP.NET Core Web API to prevent unauthorized users from accessing specific endpoints. You learned how to register your Web API application with Auth0, how to enable your ASP.NET application to support authorization, and how to use the autogenerated interactive documentation to test the endpoints.

You can download the full source code of the application from [GitHub](https://github.com/auth0-blog/glossary-web-api-aspnet/tree/add-authorization).


Authorization for ASP.NET Core Web APIs

The new Auth0 ASP.NET Core Authentication SDK makes adding authentication and authorization to your web applications a breeze.

Auth0 brings you the new [ASP.NET Core Authentication SDK](https://github.com/auth0/auth0-aspnetcore-authentication), which improves your development experience and better integrates with Auth0 features! Let's take a tour through the main features of the SDK to see how easy it becomes to integrate your ASP.NET applications with Auth0.

## The SDK Overview

So far, you were used to relying on the standard `Microsoft.AspNetCore.Authentication.OpenIdConnect` package to integrate your ASP.NET application with Auth0. That library does its job very well. However, when you move away from implementing the simple login and logout, your code starts becoming verbose until it gets messy.

You can mitigate this issue by [implementing your authentication with C# extension methods](https://auth0.com/blog/using-csharp-extension-methods-for-auth0-authentication/). But why do it yourself when the experts at Auth0 can provide you with a ready-to-use SDK?

The  [ASP.NET Core Authentication SDK](https://github.com/auth0/auth0-aspnetcore-authentication) allows you to write less code to integrate Auth0 authentication and authorization into your ASP.NET applications. It simplifies configuration, supports additional query parameters and refresh tokens, natively supports [Auth0 Organizations](https://auth0.com/docs/organizations) and user invitations. It is actually a wrapper around the `Microsoft.AspNetCore.Authentication.OpenIdConnect` library, but it brings you a standard and easy way to integrate Auth0 into your applications.

You can use the SDK for all your ASP.NET applications that require authentication, such as ASP.NET MVC apps, Razor web apps, and Blazor server apps.

## Install the ASP.NET Core Authentication SDK

You can install the Auth0 ASP.NET Core SDK by using the NuGet Package Manager UI in Visual Studio, as shown below:

![Installing the Auth0 ASP.NET SDK with NuGet Package Manager UI](https://images.ctfassets.net/23aumh6u8s0i/52AB2b6XDotBDpBlPPR1F7/f4b71a1b33c3cecb56b46d96b2e27788/installing-auth0-aspnet-core-authentication-sdk.png)

You can also install it by running the following command in the Package Manager Console:

```powershell
Install-Package Auth0.AspNetCore.Authentication
```

Or you can use the following command in a terminal window:

```bash
dotnet add package Auth0.AspNetCore.Authentication
```

Independently of your preferred approach, you will get the `Auth0.AspNetCore.Authentication` dependency in your ASP.NET project.

## The Basic Login Use Case

Let's start to take a look at the way the new SDK improves your developer experience. Of course, you need an Auth0 account to integrate your ASP.NET application with Auth0. If you haven't, you can <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">sign up for a free one</a> right now. Follow [the Auth0 ASP.NET Core Authentication SDK quickstart to register your application and get your application keys](https://auth0.com/docs/quickstart/webapp/aspnet-core#configure-auth0). 

The following is the typical code you write to enable authentication in your ASP.NET application when using `Microsoft.AspNetCore.Authentication.OpenIdConnect`:

```csharp
public void ConfigureServices(IServiceCollection services)
{
  services.AddAuthentication(options => {
    options.DefaultAuthenticateScheme = CookieAuthenticationDefaults.AuthenticationScheme;
    options.DefaultSignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
    options.DefaultChallengeScheme = CookieAuthenticationDefaults.AuthenticationScheme;
  })
  .AddCookie()
  .AddOpenIdConnect("Auth0", options => {
    options.Authority = $"https://{Configuration["Auth0:Domain"]}";
    options.ClientId = Configuration["Auth0:ClientId"];
    options.CallbackPath = new PathString("/callback");
    options.TokenValidationParameters = new TokenValidationParameters
    {
      NameClaimType = "name"
    };
    options.Events = new OpenIdConnectEvents
    {
      OnRedirectToIdentityProviderForSignOut = (context) =>
      {
        var logoutUri = $"https://{Configuration["Auth0:Domain"]}/v2/logout?client_id={Configuration["Auth0:ClientId"]}";

        var postLogoutUri = context.Properties.RedirectUri;
        if (!string.IsNullOrEmpty(postLogoutUri))
        {
          if (postLogoutUri.StartsWith("/"))
          {
            // transform to absolute
            var request = context.Request;
            postLogoutUri = request.Scheme + "://" + request.Host + request.PathBase + postLogoutUri;
          }
          logoutUri += $"&returnTo={ Uri.EscapeDataString(postLogoutUri)}";
        }

        context.Response.Redirect(logoutUri);
        context.HandleResponse();

        return Task.CompletedTask;
      }
    };
  });
}
```

I will not go through that code to explain every single step. You just need to know it implements the login and logout features in your applications by relying on the [Auth0 Universal Login](https://auth0.com/docs/login/universal-login) page.

By using the Auth0 ASP.NET Core Authentication SDK, your code shortens as follows:

```csharp
public void ConfigureServices(IServiceCollection services)
{
  services.AddAuth0WebAppAuthentication(options =>
  {
    options.Domain = Configuration["Auth0:Domain"];
    options.ClientId = Configuration["Auth0:ClientId"];
  });
}
```

Impressive, isn't it? 😲

The SDK takes care of all the configuration stuff you previously needed to do manually. And that's just the beginning! 🎉

## Get an Access Token

What if you want to call an API from your ASP.NET application? In this case, you need to [request an access token for a specific audience](https://auth0.com/docs/security/tokens/access-tokens/get-access-tokens#control-access-token-audience) to Auth0.

Doing it without the SDK would require a code similar to the following:

```csharp
public void ConfigureServices(IServiceCollection services)
{
  services.AddAuthentication(options => {
    options.DefaultAuthenticateScheme = CookieAuthenticationDefaults.AuthenticationScheme;
    options.DefaultSignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
    options.DefaultChallengeScheme = CookieAuthenticationDefaults.AuthenticationScheme;
  })
  .AddCookie()
  .AddOpenIdConnect("Auth0", options => {
    options.Authority = $"https://{Configuration["Auth0:Domain"]}";
    options.ClientId = Configuration["Auth0:ClientId"];
    //👇new code
    options.ClientSecret = Configuration["Auth0:ClientSecret"];
    options.SaveTokens = true;
    options.ResponseType = OpenIdConnectResponseType.Code;
    //👆new code
    options.CallbackPath = new PathString("/callback");
    options.TokenValidationParameters = new TokenValidationParameters
    {
      NameClaimType = "name"
    };
    options.Events = new OpenIdConnectEvents
    {
      OnRedirectToIdentityProviderForSignOut = (context) =>
      {
        var logoutUri = $"https://{Configuration["Auth0:Domain"]}/v2/logout?client_id={Configuration["Auth0:ClientId"]}";

        var postLogoutUri = context.Properties.RedirectUri;
        if (!string.IsNullOrEmpty(postLogoutUri))
        {
          if (postLogoutUri.StartsWith("/"))
          {
            // transform to absolute
            var request = context.Request;
            postLogoutUri = request.Scheme + "://" + request.Host + request.PathBase + postLogoutUri;
          }
          logoutUri += $"&returnTo={ Uri.EscapeDataString(postLogoutUri)}";
        }

        context.Response.Redirect(logoutUri);
        context.HandleResponse();

        return Task.CompletedTask;
      }
      //👇new code
      OnRedirectToIdentityProvider = context =>
      {
        context.ProtocolMessage.SetParameter("audience", Configuration["Auth0:Audience"]);
        return Task.FromResult(0);
      }
      //👆new code
    };
  });
}
```

Basically, you need to add a few more lines to the previous code in order to change the OAuth flow, provide the client secret, enable token saving, and attach the audience value to the authorization request.

The equivalent code to achieve the same result using the SDK is as follows:

```csharp
public void ConfigureServices(IServiceCollection services)
{
  services.AddAuth0WebAppAuthentication(options =>
  {
    options.Domain = Configuration["Auth0:Domain"];
    options.ClientId = Configuration["Auth0:ClientId"];
    options.ClientSecret = Configuration["Auth0:ClientSecret"];
  })
  .WithAccessToken(options =>
  {
    options.Audience = Configuration["Auth0:Audience"];
  }); 
}
```

Aren't you excited about this? 💥 Your code will be more concise, clean, and clear!

## Refresh Tokens As Magic

And in case you need a [refresh token](https://auth0.com/docs/security/tokens/refresh-tokens)? 🤔 Nothing could be simpler. Just set a flag:

```csharp
public void ConfigureServices(IServiceCollection services)
{
  services.AddAuth0WebAppAuthentication(options =>
  {
    options.Domain = Configuration["Auth0:Domain"];
    options.ClientId = Configuration["Auth0:ClientId"];
    options.ClientSecret = Configuration["Auth0:ClientSecret"];
  })
  .WithAccessToken(options =>
  {
    options.Audience = Configuration["Auth0:Audience"];
    options.UseRefreshTokens = true;   //👈 new code
  });
}
```

Compare it with the code you need to add to the SDK-less code:

```csharp
public void ConfigureServices(IServiceCollection services)
{
  services.AddAuthentication(options => {
  //...the code to configure authentication...
  })
  .AddCookie(options => {
    options.Events.OnValidatePrincipal = (context) => {
    var options = context.HttpContext.RequestServices.GetRequiredService<Auth0Options>();

    string accessToken;
    if (context.Properties.Items.TryGetValue(".Token.access_token", out accessToken))
    {
      if (options.UseRefreshTokens)
      {
        string refreshToken;
        if (context.Properties.Items.TryGetValue(".Token.refresh_token", out refreshToken))
        {
          var now = DateTimeOffset.Now;
          var expiresAt = DateTimeOffset.Parse(context.Properties.Items[".Token.expires_at"]);
          var leeway = 60;
          var difference = DateTimeOffset.Compare(expiresAt, now.AddSeconds(leeway));
          var isExpired = difference <= 0;

          if (isExpired && !string.IsNullOrWhiteSpace(refreshToken))
          {
            var result = await RefreshTokens(options, refreshToken, auth0Options.Backchannel);

            if (result != null)
            {
              context.Properties.UpdateTokenValue("access_token", result.AccessToken);
              context.Properties.UpdateTokenValue("refresh_token", result.RefreshToken);
              context.Properties.UpdateTokenValue("id_token", result.IdToken);
              context.Properties.UpdateTokenValue("expires_at", DateTimeOffset.Now.AddSeconds(result.ExpiresIn).ToString("o"));
            }
            else
            {
              context.Properties.UpdateTokenValue("refresh_token", null);
            }

            context.ShouldRenew = true;
          }
        } 
      }
    }
  })
  .AddOpenIdConnect("Auth0", options => {
    //...the code to configure OpenID Connect...
  });
}
```

You should take care of all the details about determining the token expiration and requesting a new access token. The Auth0 ASP.NET Core Authentication SDK does this on your behalf. Do you agree it's magic? ✨

## Auth0 Organizations Support

Not only the ASP.NET Core Authentication SDK lets you deal with standard OpenID Connect and OAuth duties, but it also simplifies your life in using specific Auth0 features such as [Auth0 Organizations](https://auth0.com/docs/organizations). By using Organizations, you can represent logical groups of users such as teams, partners, business customers, and so on. They can have specific policies, branding, and other customizations. So, to enable a user to log in to an organization, you need to specify it in your ASP.NET application. The following is an example of how you can accomplish this by using the SDK:

```csharp
public void ConfigureServices(IServiceCollection services)
{
  services.AddAuth0WebAppAuthentication(options =>
  {
    options.Domain = Configuration["Auth0:Domain"];
    options.ClientId = Configuration["Auth0:ClientId"];
    options.Organization = Configuration["Auth0:Organization"];
  });
}
```

Pretty straightforward, right? 🙌 Of course, you can do more with Organizations. Please, take a look at [the ASP.NET Core Authentication SDK documentation](https://github.com/auth0/auth0-aspnetcore-authentication#organization) to learn more.

## Customization

At this point, you may think that having an SDK forces you to use its methods to work with OpenID Connect and OAuth. So you no longer have the freedom of adding extra parameters to the authorization request, for example. Or you may think you can't anymore apply your custom token validation or freely manage OpenID Connect events.

I have good news: you don't need to worry about this. The ASP.NET Core Authentication SDK leaves you the freedom to customize many things.

For example, you can add custom parameters to the authorization request. Look at the following example:

```csharp
public void ConfigureServices(IServiceCollection services)
{
  services.AddAuth0WebAppAuthentication(options =>
  {
    options.Domain = Configuration["Auth0:Domain"];
    options.ClientId = Configuration["Auth0:ClientId"];
    options.LoginParameters = new Dictionary<string, string>() { 
      { "screen_hint", "signup" } 
    };
  }); 
}
```

Here you configured your ASP.NET application to attach the `screen_hint` parameter with the `signup` value  to the authorization request. In this specific case, the user will see the signup window instead of the default login screen.

But you can also apply your custom validation, as in the following case:

```csharp
public void ConfigureServices(IServiceCollection services)
{
  services.AddAuth0WebAppAuthentication(options =>
  {
    options.Domain = Configuration["Auth0:Domain"];
    options.ClientId = Configuration["Auth0:ClientId"];
    options.OpenIdConnectEvents = new OpenIdConnectEvents
    {
      OnTokenValidated = (context) =>
      {
        var birthDateClaim = context.SecurityToken.Claims.SingleOrDefault(claim => claim.Type == "birthdate")?.Value;

        if (string.IsNullOrWhiteSpace(birthDateClaim))
        {
          context.Fail("The 'birthdate' claim must be present in the ID token.");
        }
            
        return Task.CompletedTask;
      }
    };
  })
}
```

As you can see, the ASP.NET Core Authentication SDK exposes the `OpenIdConnectEvents` option to let you handle the standard events triggered by the `Microsoft.AspNetCore.Authentication.OpenIdConnect` library. This way, you can combine the SDK simplicity with the standard library behavior to get the maximum flexibility.

## Summary

Now you should have a clearer idea about the benefits you have by using the ASP.NET Core Authentication SDK to integrate Auth0 into your ASP.NET applications: less code, more readability, flexibility, and best practices inside. So, give a try to the SDK and integrate your [ASP.NET applications with Auth0 by following the QuickStart](https://auth0.com/docs/quickstart/webapp/aspnet-core). Check out [the SDK documentation](https://auth0.github.io/auth0-aspnetcore-authentication/) to learn more.

You can also [contribute to it](https://github.com/auth0/auth0-aspnetcore-authentication#contributing): it's open-source!

Exploring the Auth0 ASP.NET Core Authentication SDK

abhishek-chanda

I am a backend/platform engineer focusing on making application deployments easier.

Senior Systems Engineer

Abhishek Chanda

Learn how to implement a simple REST API with JWT Authentication in Rust using the actix web framework and Diesel.

Build an API in Rust with JWT Authentication

Learn how to use Passport.js to add user authentication to a web app built with Node.js and Express.

Node.js and Express Authentication Using Passport

kaycie-east

As PR Manager, Kaycie supports public relations and global communications efforts for Auth0 in the AMER region. When not promoting the Auth0 brand, Kaycie can be found hiking, traveling, or searching for the next best bite to eat.

PR Manager, AMER Region

Kaycie East

New feature removes the need for passwords and offers unique progressive enrollment features, paving the way for the ultimate user experience.


**BELLEVUE, Wash. – June 15, 2021 –** The [Auth0](https://auth0.com/) Identity Platform, a product unit within Okta, today announced the launch of [Auth0 WebAuthn Passwordless](https://auth0.com/passwordless), an authentication feature that enables end-users to seamlessly log in with a biometric identifier — such as facial recognition or a fingerprint — as a convenient and secure alternative to a traditional password. Removing the need for long, complex passwords, Auth0 WebAuthn Passwordless provides a frictionless experience for end-users while reducing the significant password management burden for companies. 

<include src="WebAuthnMeCTA" group="B"/>

Today’s abundance of applications and systems have never had more access points, leaving organizations and their end-users vulnerable to attacks. A reliance on passwords as a primary means of authentication, combined with users’ tendency to re-use passwords across applications, presents a number of security, user experience, and cost issues. According to a [2021 Data Breach Investigations Report by Verizon](https://www.verizon.com/business/resources/reports/dbir/), compromised passwords are responsible for 84% of breaches. Passwordless authentication mitigates these challenges and offers increased security and trust for applications, devices, and services providers; faster and smoother login experiences for their end-users; and cost savings by eliminating the need for password management support. 

“Despite ongoing guidance around proper password creation and repeated warnings against password reuse, consumers crave convenience and continue to use the easiest and most convenient path for application access,” said Shiv Ramji, Chief Product Officer at Auth0. “A passwordless future is largely being driven by two primary forces — security and convenience. Companies want to secure the vulnerabilities that come with passwords, and they also want to offer their users a better digital experience. Auth0 WebAuthn Passwordless is a modern option for organizations looking to attract and retain users.”

With Auth0 WebAuthn Passwordless, users can authenticate with Web Authentication-powered (WebAuthn) biometrics, the official web standard for passwordless authentication as published by [W3C and used by FIDO](https://fidoalliance.org/fido2/fido2-web-authentication-webauthn/), for first-factor authentication. This form of authentication eliminates security weaknesses based on password reuse since passwords are not required. Additionally, Auth0 WebAuthn Passwordless is an ideal option for companies looking to build and provide an authentication experience supporting conversion and retention of users who want more choice and less friction in their login experience.

Auth0 WebAuthn Passwordless eliminates the need for users to enter username and password credentials and enables simpler login with a biometric identifier such as facial recognition like Apple Face ID or a fingerprint scan on a mobile device or laptop. The biometric data remains stored on the device, alleviating privacy and security concerns for end-users. The feature also allows end-users to progressively enroll devices one at a time, as they use them, without needing a centralized portal, giving them the flexibility of having multiple passwordless authentication options — an advanced, unique capability that maximizes end-user adoption and enables a faster transition from passwords to passwordless, benefiting both end-users and organizations.

More detailed information on Auth0 WebAuthn Passwordless can be found here: [7 Things You Need to Know About Passwordless Authentication](https://auth0.com/resources/whitepapers/passwordless-authentication) (whitepaper) and on [Auth0’s blog](https://auth0.com/blog/freedom-from-passwords-with-auth0-webauthn-passwordless). 

[Auth0, recently acquired by Okta](https://auth0.com/blog/okta-acquisition-announcement/), provides a modern identity platform that helps organizations meet the security, privacy, and convenience needs of their users. Please visit [The Auth0 Identity Platform](https://auth0.com/identity-os) to learn more.


<include src="asides/AboutAuth0" />
### Media Contacts
Global Communications<br />
Auth0 <br />
[press@auth0.com](mailto:press@auth0.com)<br />

Matter for Auth0<br />
[auth0@matternow.com](mailto:auth0@matternow.com)<br />

Auth0 WebAuthn Passwordless Offers New Levels of Ease and Security for Modern Authentication

1097492785caf9ffeebffeb624202d8f?s=200 avatar

1097492785caf9ffeebffeb624202d8f?s=200

Prosper is a great speaker, community leader, open source hacker, technical consultant, and a fervent Developer Advocate. He is a full-stack software engineer who has worked on biometric, health and developer tools. Prosper recently co-founded a startup called Eden that’s focused on improving the quality of lives in Nigeria and currently leads the engineering team. He also co-founded forloop, the largest developer community in Africa.

Former Auth0 Employee

Prosper Otemuyiwa

Let’s learn how to use Meteor to build a real-time web application and add authentication to it

Developing Real-time Apps with Meteor

andres

I’ve been at Auth0 since 2017. I’m currently working as a Product Manager for the Auth0 FGA and OpenFGA products. Previously, I worked in the teams that owned the Login and MFA flows. <br>
I spent my entire 20+ year career building tools for developers, wearing different hats. When I'm not doing that, I enjoy spending time with my family, singing in a choir, cooking, or trying new kinds of local cheese.

Product Manager

Andrés Aguiar

Announcing support for WebAuthn with FIDO Security Keys for Multi-Factor Authentication in Auth0



Companies of all sizes are under attack, targeted by numerous phishing attacks that are coming at an ever-increasing rate. Even if the tech industry continues to improve how organizations identify and defend against those attacks, the problem is bigger than ever. According to ProofPoint's [2020 State of The Phish Annual Report](https://www.proofpoint.com/sites/default/files/gtd-pfpt-uk-tr-state-of-the-phish-2020-a4_final.pdf), 88% of organizations faced a targeted phishing attack in 2019, and 65% of US organizations experienced a **successful** phishing attack.

There are options for decreasing the chances of successful phishing attacks targeting your company. Things like employee training and security policies, such as using password managers and enforcing multi-factor authentication (MFA), are all steps in the right direction. 

However, if you want to neutralize the threat completely, you need to enable authentication methods that cannot be phished. That's [what Google did](https://krebsonsecurity.com/2018/07/google-security-keys-neutralized-employee-phishing) in 2017 to neutralize phishing of its employees. Google now requires all employees to use U2F Security Keys to authenticate to corporate websites. 

U2F evolved into the WebAuthn specification, which is now supported by the latest versions of browsers and operating systems. Auth0 is now supporting WebAuthn with FIDO security keys for multi-factor authentication. You can start protecting your users with Auth0 today, using the same technology as Google.

## About WebAuthn

The Web Authentication API (also known as WebAuthn) is a [specification](https://www.w3.org/TR/webauthn/) written by the World Wide Web Consortium (W3C) and The Fast IDentity Online Alliance, known as FIDO, with the participation of Google, Mozilla, Microsoft, Yubico, and others. The API allows servers to register and authenticate users with public-key cryptography instead of a password.

When it comes to security, many people think you have to sacrifice security in the name of user experience, and vice versa. However, the key to maximizing both variables is to reduce the number of times we prompt the user for authentication and to allow the user to authenticate with secure factors that provide low friction. WebAuthn promises to be the holy-grail of authentication factors, as it accomplishes exactly that by combining maximum security with a low-friction user experience.

WebAuthn allows users to authenticate using one of two options:

* **Roaming authenticators** — These are removable and cross-platform devices, like a [Yubikey](https://www.yubico.com/products/) that can be used on multiple devices. To authenticate with a roaming authenticator, you simply connect it to the device (through USB, NFC, or Bluetooth), provide proof of presence (e.g., touching it), and optionally an additional authentication factor like a PIN or fingerprint recognition.

* **Platform authenticators** — This option includes the MacBook's TouchBar, Windows Hello, iOS Touch/FaceId, and Android's fingerprint/face recognition. Integrated into the device being used, these only work on that device.

When doing multi-factor authentication, we want to challenge the user with something they know (like a password), something they have (like a security key), and something they are (e.g., their fingerprint).

Note that a Roaming Authenticator + PIN **combines two factors in one** (you have the key, and you know the pin), and a Platform Authenticator also does (you have the device, you are the person with that fingerprint/face, or you know the passcode).

In recent months the WebAuthn API has been implemented in major browsers and operating systems, enabling support for both options.

<include src="WebAuthnMeCTA" group="A"/>

## The Case for Security Keys

Using a Security Key allows you to authenticate users with the strongest possible authentication factor. This helps you to solve several problems at once by:

* Protecting sensitive data and employee accounts
* Providing secure access from outside the corporate network
* Allowing your employees to authenticate to shared computers
* Enabling MFA in scenarios where users cannot carry their mobile phone

It also offers several advantages when compared with using a smartphone only authenticator for MFA:

* Protects against phishing and man-in-the-middle attacks
* Strengthens user privacy as it doesn't require a personal device
* Provides one-touch login without having to take your mobile phone to complete an authentication challenge
* Has no battery or signal dependency
* Has no moving parts, so it's practically indestructible
* Allows users to register multiple keys, minimizing business disruption and the chances of account lockout

## WebAuthn With Security Keys for Multi-Factor Authentication

Auth0 with WebAuthn support for Security Keys is available starting today. You can enable the factor in the WebAuthn with Security Keys MFA configuration section of the admin dashboard:

![Multi-Factor Authentication 1](https://images.ctfassets.net/23aumh6u8s0i/5LAUWUPRO5gvYQ9t56rNPa/f9c2d823965b8070c22e6ab3151d2665/01-factors-updated)

After it is enabled, users will go through the enrollment flow below. At some point, their browser will show a native dialog to ask users to engage the security key. In the example below, we show the Android dialog:

![Multi-Factor Authentication 2](https://images.ctfassets.net/23aumh6u8s0i/4l0n2zVBk0Byf8P2MfWvaf/51a1b3ebb7248719a7cc17b32a4765a4/02-welcome)

The next time they login, the flow will look like this:

![Multi-Factor Authentication 3](https://images.ctfassets.net/23aumh6u8s0i/5f9tqz1pR3RgrkFZSOcp2F/41df6128ee37f040c0389dbd7db9dda8/03-waiting-for-your)

## Stay Tuned!

In addition to supporting WebAuthn with roaming authenticators, we are currently working on a unique approach that will greatly improve the usability and adoption of WebAuthn platform authenticators. Check out Vittorio Bertocci's session "[Democratizing WebAuthn for Developers and End Users](https://authenticatecon.com/session/democratizing-webauthn-for-developers-and-end-users/)" from FIDO's Authenticate conference for the scoop!

WebAuthn is an exciting technology, and Auth0 is committed to providing the best possible implementation, maximizing security without sacrificing user experience. Check out our new [WebAuthn](https://auth0.com/docs/mfa/configure-webauthn-security-keys-for-mfa) offering and let us know what you think on our [Feedback page](https://auth0.com/feedback) or in the [Auth0 Community](https://community.auth0.com).

<include src="asides/AboutAuth0" />


FIDO Security Key Support Comes To Auth0

Learn how to add user authentication to Node.js web apps built with Express using middleware

The Complete Guide to Node.js User Authentication with Auth0

ramiro

I am an internet guy who loves reading and asking questions—those are the two things that helped me the most as an autodidact 🤓. If I am not learning about the latest trends in digital marketing or listening to house music, you can probably find me watching a tennis tournament. And also, I manage Social Media at Auth0 ✌️

Manager, Social Media

Ramiro Nunez Dosio

Our 10 most-popular identity posts in 2018 ranging from auth standards to web authentication.



Time flies when you are having fun. It's December already and we are getting ready to wrap up this year. 2018 was a prolific year for the Auth0 blog: we published more than 200 posts (😱) where we tackled a diverse amount of topics: frontend and backend technologies, data breaches, GDPR, Cybersecurity, Company Culture, and of course, Identity.

We believe looking back is key to look ahead. That is why this week, we are going to take a look back at the best and most impactful posts we have published in 2018.

One article wouldn't be enough to review this amazing year, that's why we have decided to split this year in review into 3 parts: [Developer Posts](https://auth0.com/blog/10-most-popular-developer-posts-in-2018/), [Security Posts](https://auth0.com/blog/10-most-popular-security-posts-in-2018/), and Identity Posts.

Without much further ado, here's the roundup of our 10 most-popular Identity posts this year!

![Auth0's 10 Most-Popular Identity Posts](https://images.ctfassets.net/23aumh6u8s0i/2PZojrBsthRTB6sKxDI0nw/cf5db7303eafa89f7ef46b4bc5f05e81/identity-posts)

## Auth0's 10 Most-Popular Identity Posts in 2018

> The following posts are not listed in any particular order.

1. <a href="#an-overview-of-open-standards" target="_self">An Overview of Open Standards</a>
2. <a href="#3-iam-examples-to-support-digital-transformation" target="_self">3 IAM Examples to Support Digital Transformation</a>
3. <a href="#a-look-at-the-draft-for-jwt-best-current-practices" target="_self">A Look at The Draft for JWT Best Current Practices</a>
4. <a href="#introduction-to-web-authentication-the-new-w3c-spec" target="_self">Introduction to Web Authentication: The New W3C Spec</a>
5. <a href="#how-to-have-a-successful-idm-project" target="_self">How To Have a Successful IDM Project</a>
6. <a href="#how-to-have-a-successful-idm-project-part-2" target="_self">How To Have a Successful IDM Project (Part 2)</a>
7. <a href="#on-the-nature-of-oauth2s-scopes" target="_self">On The Nature of OAuth2’s Scopes</a>
8. <a href="#hashing-passwords-one-way-road-to-security" target="_self">Hashing Passwords: One-Way Road to Security</a>
9. <a href="#adding-salt-to-hashing-a-better-way-to-store-passwords" target="_self">Adding Salt to Hashing: A Better Way to Store Passwords</a>
10. <a href="#how-utilities-can-use-ciam-to-avoid-3-common-problems" target="_self">How Utilities Can Use CIAM to Avoid 3 Common Problems</a>

## <a name="an-overview-of-open-standards"></a>1. [An Overview of Open Standards](https://auth0.com/blog/an-overview-of-open-standards/)

In this overview, we will go over what open standards are and why they matter. We will also go over the top open standards used for identity including OAuth 2, OpenID Connect, JWT, and SAML. Open standards are important to understand but one can easily get overwhelmed by the technical specifications.

<include src="ClickImg" externalUrl="https://auth0.com/blog/an-overview-of-open-standards/" imgUrl="https://cdn.auth0.com/blog/10-most-popular-identity-posts-in-2018/open-certificationpng.png" altText="Open Certification" imgWidth="560" imgHeight="560"/>

## <a name="3-iam-examples-to-support-digital-transformation"></a>2. [3 IAM Examples to Support Digital Transformation](https://auth0.com/blog/3-iam-examples-to-support-digital-transformation/)

From basic website authentication to implementing an OpenID Connect server and API authentication: This article covers 3 IAM examples to support your Digital Transformation.

<include src="ClickImg" externalUrl="https://auth0.com/blog/3-iam-examples-to-support-digital-transformation/" imgUrl="https://cdn.auth0.com/blog/iam-digital-transform/sso-data-model.png" altText="SSO Data Model" imgWidth="714" imgHeight="559"/>

## <a name="a-look-at-the-draft-for-jwt-best-current-practices"></a>3. [A Look at The Draft for JWT Best Current Practices](https://auth0.com/blog/a-look-at-the-latest-draft-for-jwt-bcp/)

In this post, we will take a look at the draft for the JWT Best Current Practices document. This document describes common pitfalls and attacks related to the use of JWTs, and how to implement mitigations against them. Read on!

<include src="ClickImg" externalUrl="https://auth0.com/blog/a-look-at-the-latest-draft-for-jwt-bcp/" imgUrl="https://cdn.auth0.com/blog/jwt-bcp/Substitution-Attack-Different-Recipient.png" altText="Different Recipient JWT Substitution Attack" imgWidth="590" imgHeight="492"/>

## <a name="introduction-to-web-authentication-the-new-w3c-spec"></a>4. [Introduction to Web Authentication: The New W3C Spec](https://auth0.com/blog/introduction-to-web-authentication/)

Web Authentication brings a stronger authentication mechanism to the masses by defining an API that both authenticators and web browsers can implement. Learn why Google, Paypal, Mozilla, and others back it up.

<include src="ClickImg" externalUrl="https://auth0.com/blog/introduction-to-web-authentication/" imgUrl="https://cdn.auth0.com/blog/webauthn/1-Web-Authentication-Entities.png" altText="Web Authentication Entities" imgWidth="617" imgHeight="409"/>

## <a name="how-to-have-a-successful-idm-project"></a>5. [How To Have a Successful IDM Project](https://auth0.com/blog/how-to-have-a-successful-idm-project/)

Learn how to create a realistic project plan to have a good Identity Management project deployment.

<include src="ClickImg" externalUrl="https://auth0.com/blog/how-to-have-a-successful-idm-project/" imgUrl="https://cdn.auth0.com/blog/good-idm-project/enabling-mfa.png" altText="Eanbling Multi-factor Authentication (MFA) from Auth0" imgWidth="617" imgHeight="361"/>

## <a name="how-to-have-a-successful-idm-project-part-2"></a>6. [How To Have a Successful IDM Project (Part 2)](https://auth0.com/blog/how-to-have-a-successful-idm-project-part-2/)

Learn how to plan for failures and changes in your identity project.

<include src="ClickImg" externalUrl="https://auth0.com/blog/how-to-have-a-successful-idm-project-part-2/" imgUrl="https://cdn.auth0.com/blog/how-to-have-a-successful-idm-project-part-2/resetting-a-users-multi-factor-account-with-auth0.png" altText="Resetting a user's multi-factor account" imgWidth="617" imgHeight="439"/>

## <a name="on-the-nature-of-oauth2s-scopes"></a>7. [On The Nature of OAuth2’s Scopes](https://auth0.com/blog/on-the-nature-of-oauth2-scopes/)

Auth0 Principal Architect and Identity expert Vittorio Bertocci on why using OAuth2 scopes in every authorization scenario is not a good idea.

<include src="ClickImg" externalUrl="https://auth0.com/blog/on-the-nature-of-oauth2-scopes/" imgUrl="https://cdn.auth0.com/blog/on-the-nature-of-oauth2-scopes/oauth2-scopes-mail-api.png" altText="OAuth2 Scopes Mail API exmaple" imgWidth="617" imgHeight="280"/>

## <a name="hashing-passwords-one-way-road-to-security"></a>8. [Hashing Passwords: One-Way Road to Security](https://auth0.com/blog/hashing-passwords-one-way-road-to-security/)

A strong password storage strategy is critical to mitigating data breaches that put the reputation of any organization in danger. Hashing is the foundation of secure password storage.

<include src="ClickImg" externalUrl="https://auth0.com/blog/hashing-passwords-one-way-road-to-security/" imgUrl="https://cdn.auth0.com/blog/hashing-one-way-road-to-security/hash-flow.png" altText="Hashing algorithm flow example - one-way" imgWidth="617" imgHeight="340"/>

## <a name="adding-salt-to-hashing-a-better-way-to-store-passwords"></a>9. [Adding Salt to Hashing: A Better Way to Store Passwords](https://auth0.com/blog/adding-salt-to-hashing-a-better-way-to-store-passwords/)

A salt is added to the hashing process to force their uniqueness, increase their complexity without increasing user requirements, and to mitigate password attacks like rainbow tables

<include src="ClickImg" externalUrl="https://auth0.com/blog/adding-salt-to-hashing-a-better-way-to-store-passwords/" imgUrl="https://cdn.auth0.com/blog/adding-salt-to-hashing-a-better-way-to-store-passwords/password-salt-example.png" altText="Example showing how using a salt with hashing produces unique hashes." imgWidth="617" imgHeight="277"/>

## <a name="how-utilities-can-use-ciam-to-avoid-3-common-problems"></a>10. [How Utilities Can Use CIAM to Avoid 3 Common Problems](https://auth0.com/blog/how-utilities-can-use-ciam-to-avoid-3-common-problems/)

Customer identity and management technology helps utilities reshape how they interact with users, improve their services, and tighten security.

<include src="ClickImg" externalUrl="https://auth0.com/blog/how-utilities-can-use-ciam-to-avoid-3-common-problems/" imgUrl="https://cdn.auth0.com/blog/how-utilities-can-use-ciam-to-avoid-3-common-problems/progressive-profiling-flow.png" altText="Utility customer progressive profiling flow" imgWidth="617" imgHeight="303"/>

## What's Next?

We are already preparing our content pipeline for 2019. Identity and digital transformation are key areas that will keep businesses evolving to tackle challenges around privacy, usability, growth, and sociopolitical policies. We are committed to keep our content relevant to these changes and offer effective solutions through our products and services.

We'd like to take this opportunity to thank all of our readers for their consistent support and feedback. Is there anything that you'd like us to cover in 2019? Any particular identity topic or trend? Please let us know in the comments below or through social media ([Twitter](https://twitter.com/auth0), [LinkedIn](https://www.linkedin.com/company/auth0)). As always, you can subscribe to our newsletter to receive a weekly digest of our blog content.

Happy Holiday Season!

<include src="asides/AboutAuth0" />


10 Most-Popular Identity Posts in 2018

Learn about WebAuthn, a new standard for secure authentication on the web.


[News](https://www.engadget.com/2018/05/09/mozilla-firefox-passwords-web-authentication-support/) about [Web Authentication](https://webauthn.me/introduction), or WebAuthn for short, reaching maturity and being enabled by default in web browsers hit the headlines recently. Web Authentication is a fairly recent W3C standard backed by major players like Google, Paypal, Mozilla, Microsoft, and Qualcomm. It aims at defining a web-browser API for the creation and use of strong authentication credentials based on public key cryptography. The driving force behind the proposal is to increase security for the authentication process by removing or complementing password-based authentication while remaining convenient for end-users. Although implementations are still in their early days, and the standard has not been finalized, the strong push from major players, and the fact that both Firefox and Chrome are enabling their implementations by default, are strong indicators that this may cause a significant impact in the authentication space. Let's check it out!

<include src="WebAuthnMeCTA" group="A"/>

---

## Introduction
The traditional username/password scheme for user authentication has been in use for decades. Even in the face of modern approaches like social logins and [Face ID](https://en.wikipedia.org/wiki/Face_ID), username and passwords remain the most popular and widely used mechanism for authentication. Stronger authentication mechanisms such as certificates and hardware tokens have been supported for a long time for specific applications and use cases, but they remain unusual for end users.

Most of the authentication flows performed by end users are done through web browsers. In a sense, web browsers have become the nexus between credentials and applications on the two major platforms: desktop and mobile. It is natural, then, that changes to authentication flows require support from browsers. The web, however, is built on consensus. This means that changes to the platform need to be implemented by several players. For this reason, the W3C WebAuthn Working Group was formed: to produce a new specification that can be implemented by all parties and that remains interoperable.

The draft specification says:

> This specification defines an API enabling the creation and use of strong, attested, scoped, public key-based credentials by web applications, for the purpose of strongly authenticating users.

<include src="TweetQuote" quoteText="Web Authentication defines an API enabling the creation and use of strong, attested, scoped, public key-based credentials by web applications, for the purpose of strongly authenticating users."/>

To better understand Web Authentication, let's go through a quick overview.

## Web Authentication In a Nutshell
Let's take a look at the entities involved in WebAuthn:

![Web Authentication (WebAuthn) Entities](https://images.ctfassets.net/23aumh6u8s0i/5c7KKyElhmYWEPB4R8TQje/d46dec602523f6af3cb4d68b03e15232/1-Web-Authentication-Entities.png)

These entities work together in two separate use cases: **registration** and **authentication**. All communications between the different entities in the diagram are handled by the user agent (usually a web browser).

Registration makes the authenticator create a new set of public-key credentials that can be used to sign a challenge generated by the relying party. The public part of these new credentials, along with the signed challenge, can be sent back to the relying party for storage. The relying party can later use these credentials to verify the identity of a user whenever required.

![Web Authentication (WebAuthn) Registration](https://images.ctfassets.net/23aumh6u8s0i/2xxX1F2zya0XdsiCRz5dXk/3c3350168175e59b2e41be8afda3e9fd/2-Registration.png)

Authentication, in contrast, allows the relying party to send a challenge to the authenticator. This challenge can then be signed with the previously generated public-key credentials and sent back to the relying party. This way, the relying party can verify that a user is in possession of the required credentials, proving their identity.

![Web Authentication (WebAuthn) Authentication](https://images.ctfassets.net/23aumh6u8s0i/6iz4I2CXCV5CW7qNaSknTK/88fe1dd04f4bdde733d11f1fd947cfe4/3-Login.png)

Both processes work with the help of public-key cryptography and digital signatures. If you are not familiar with how public-key cryptography or digital signatures work, the important thing you must know is that there is a public key and a private key. The private key is secret, and only the user (or the authenticator) must know it. The public key, in contrast, is public and can be seen or stored by anyone. The public key can be used to verify signatures generated by the private key. No other key, other than the private key, can generate a signature that the public key can verify as valid. This way, the relying party can store a public key and use it to verify signatures performed by the user holding the private key.

Let's take a quick look at the actual API.

### API
The Web Authentication API has two main calls: [`navigator.credentials.create`](https://www.w3.org/TR/webauthn/#createCredential), and [`navigator.credentials.get`](https://www.w3.org/TR/webauthn/#getAssertion). There is also an [accessory API to list authenticators](https://www.w3.org/TR/webauthn/#isUserVerifyingPlatformAuthenticatorAvailable).

`create` can be used to perform the registration step. `get` can be used to perform the authentication step.

Here is a sample call of the `create` function inside an [EJS](http://ejs.co/) template:

```javascript
navigator.credentials.create({
  publicKey: {
    // random, cryptographically secure, at least 16 bytes
    challenge: base64url.decode('<%= challenge %>'),
    // relying party
    rp: {
      name: 'Awesome Corp' // sample relying party
    },
    user: {
      id: base64url.decode('<%= id %>'),
      name: '<%= name %>',
      displayName: '<%= displayName %>'
    },
    authenticatorSelection: { userVerification: "preferred" },
    attestation: 'direct',
    pubKeyCredParams: [
      {
        type: "public-key", alg: -7 // "ES256" IANA COSE Algorithms registry
      }
    ]
  }
}).then((res) => {
  var json = publicKeyCredentialToJSON(res);
  // Send data to relying party's servers
  post('/webauthn/register', {
    state: '<%= state %>',
    provider: '<%= provider %>',
    res: JSON.stringify(json)
  });
}).catch(console.error);
```

Here is a sample call of the `get` function in an EJS template:

```javascript
navigator.credentials.get({
  publicKey: {
    // random, cryptographically secure, at least 16 bytes
    challenge: base64url.decode('<%= challenge %>'),
    allowCredentials: [ {
      id: base64url.decode('<%= id %>'),
      type: 'public-key'
    }],
    timeout: 15000,
    authenticatorSelection: { userVerification: "preferred" },
  }
}).then((res) => {
  var json = publicKeyCredentialToJSON(res);
  // Send data to relying party's servers
  post('/webauthn/authenticate', {
    state: '<%= state %>',
    provider: '<%= provider %>',
    res: JSON.stringify(json)
  });
}).catch(err => {
  alert('Invalid FIDO device');
});
```

But the cool thing about all of this is that you don't need to care about any of it! If you use Auth0, you don't need to understand the gritty details of Web Authentication to use it.

<include src="TweetQuote" quoteText="Web Authentication at Auth0 will work with the flip of a switch!"/>

## A Working Web Authentication Implementation at Auth0
One of the cool things about our architecture is that changes in the login system can be integrated with little or no changes to client code. In other words, once our implementation of Web Authentication is released, enabling it for your apps will be a matter of making a few clicks in the [Auth0 Dashboard](https://manage.auth0.com/).

This is a proof-of-concept of how WebAuthn as a second factor will work in Auth0:

<video src="https://cdn.auth0.com/blog/webauthn/Auth0-Web-Authentication-2-small.mp4" title="Web Authentication proof-of-concept video - WebAuthn as a second factor with Auth0" controls autoplay loop></video>

What you see in this video is already working internally. We are eager to finish the implementation so you can start enabling Web Authentication in your apps.

Of course, there is more to Web Authentication than just using it as a second factor. We are also planning to enable Web Authentication as a **primary login solution**, that is, as a **passwordless login** mechanism. If you are not familiar with passwordless login and how it works, [take a look at our introduction](https://auth0.com/passwordless). Can you imagine logging in to your bank with just a push of your USB authenticator's button? <a href="https://a0.to/blog_signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">Sign up for an Auth0 account</a> and start improving your logins today. When WebAuthn integration is ready, enabling it for your apps will be a breeze.

<include src="TweetQuote" quoteText="Web Authentication (a.k.a. WebAuthn) is backed by major players in the industry, let's find out what it's all about!"/>

## Conclusion
Web Authentication brings a stronger authentication mechanism to the masses by defining an API that both authenticators and web browsers can implement. With the release of [Firefox 60](https://www.mozilla.org/en-US/firefox/60.0/releasenotes/) and [Chrome 67](https://www.chromium.org/developers/calendar), Web Authentication has become available to a big number of users. Authenticators, such as [Yubikeys](https://www.yubico.com/), already support the necessary protocols and work with current implementations. At Auth0 we care about providing the necessary building blocks for your identity infrastructure, and Web Authentication could eventually become a major improvement in security and user experience. If you would like to use Web Authentication with Auth0 for your product, let us know in the comments, or [contact us through our "Talk to Sales" contact form](https://auth0.com/).


Introduction to Web Authentication: The New W3C Spec

avatar

Jared has worked alongside founding teams to define and deliver products which are critical to Fortune 500 enterprises and small businesses, enjoyed by consumers, and depended on by developers. Along the way, he's helped grow multiple companies from a handful of people to hundreds of employees, financial stability, and successful acquisitions. Additionally, Jared is an active contributor to open source software. He is the lead developer of Passport.js, the popular authentication framework for Node.js. Downloaded over 2 million times per month, it powers authentication for innumerable applications on the Internet. He has a portfolio of over 300 repositories freely available on GitHub.

Jared Hanson

From basic website authentication to implementing an OpenID Connect server and API authentication: This article covers 3 IAM examples to support your Digital Transformation.



**TL;DR:** We recently [hosted a webinar](https://resources.auth0.com/webinars/3-iam-examples/) that covered modern identity management and what it takes to implement both Authentication and Authorization to support your Digital Transformation. In this article, we'll cover these implementations ranging from basic authentication, to an OpenID Connect server, and API authentication.


## Introduction
Identity and Access Management (IAM) encompasses the security protocols and processes that allow the correct users to access the correct content, at the correct times.  Cloud-based IAM providers, such as _Auth0_, have created simpler and more intuitive ways of managing user access, and they form an important part of **digital transformations.**

<include src="TweetQuote" quoteText="Identity and Access Management (IAM) is the security and process that allows the correct users to access the correct content, at the correct times."/>

Digital transformation, for those unaware, is not just a buzzword. It encapsulates the process of heavily utilizing modern, digital technologies to radically change businesses.

> Look beyond the hype and you'll find a daunting task at the heart of digital transformation. Rather than focusing on any single IT project, digital transformation describes a series of projects that, together, change every facet of an organization, from back office operations to customer interactions, often with the end goal of making these different processes intrinsically linked.

[http://www.itpro.co.uk/strategy/28047/what-is-digital-transformation](http://www.itpro.co.uk/strategy/28047/what-is-digital-transformation)

As we go through this article, we will cover three _IAM_ use cases. Firstly, we will cover implementing authentication on a basic website. This is the situation most people will find themselves in and the most common use case of the three. Once we've covered basic website authentication, we will move onto standard federated logins.

The second scenario we will cover is _**Enterprise SSO**_. We shall create a fake example company named _Acme,_ whos enterprise customers demand a way of logging into Acme's various services without having to remember a range of username and passwords. By using OpenID Connect, we will show how they can allow their customers' employees to log in with corporate credentials.

Finally, we will cover API integration. When we want to allow our customers to integrate our service into their line-of-business applications in custom ways.


## A Basic Website
Something we're all familiar with is the basic user registration and login that we find on our favorite websites. To access various areas and features of most websites, we usually have to create an account with them. From a high level, all this consists of is a database containing our usernames/email addresses and a complex hash of our passwords (hopefully).  Throughout this article, we'll use an example data model in which crucially, the core Users table will never change the schema, only the data references will change. The basic data model looks like this:

![Basic Data Model](https://images.ctfassets.net/23aumh6u8s0i/74wMh29yR35x1gyeASUrmv/9e037c843a6ff03b59be3420a7945677/basic-data-model)

Our sample data model is that of a simple project management tool, in which Users own Projects. Very basic. Now, what we need is a way for our users to register their details for our application.

![Basic Registration](https://images.ctfassets.net/23aumh6u8s0i/3L7FmaYEjSOGrUdOexyRdw/9e8c66dd6e21383e06694f5db8490da6/basic-registration)

As you can see in the image, our app now contains a standard sign up for new users to register for our service. From a back end perspective, the form uses a `POST` action to submit the form data to our `/signup` resource. Our back end then writes this data to our chosen database and forwards the user onto the specified route upon successful completion. Once we have a user signup implemented, a user login is the next thing we need to address. The basic login flow for our simple web app looks like this:

![Basic Login](https://images.ctfassets.net/23aumh6u8s0i/1Ku7YSRGdgbf5xOoEpUnxQ/55c563b1aaa309b085de6fcfa8a72b6f/basic-login)

In our login flow, users submit their email address and password, which issues a `POST` request to our `/login` resource. Our application back end takes the credentials supplied, issues a database lookup and ensures the details are correct. If so, our app will issue a HTTP forward request onto the specified resource, containing a Session Cookie.

In the image above, you can see that the Session Cookie is set as a HTTP Header, and is actually the most important factor in this flow. The Cookie will contain tokenized information about our users perhaps including metadata such as the user's name and avatar, so as to reduce database hits going through our web app. Besides containing the user's metadata, the Session Cookie is (more importantly) also the authorization credential for all subsequent requests as the user browses our application.

With this implemented, our application now has a basic user authentication system set up. Being basic, there are many features that we haven't addressed here, but that would really need implementing. Password hashing, password complexity verification, password reset functionality, and multi-factor authentication to name a few. Luckily, by using a system such as [Auth0's Hosted Login](https://auth0.com/docs/hosted-pages/login), we save the worry of having to implement these, as they come as standard. Out of the box, Auth0 offer the features mentioned above plus many more. You can have a fully functional user management system setup in minutes.


## Single Sign On (SSO) for Enterprise
If you've used services such as Amazon Web Services, Slack, GitHub or Salesforce, you will notice that they all have a Single Sign On (SSO) implementation so that users can access those services with their corporate credentials. As we add SSO federated capabilities into our sample application, we do have one constraint in that (as mentioned above), we do not want to change the data table schema.

![SSO Data Model](https://images.ctfassets.net/23aumh6u8s0i/6M9ZrX0pYtMQlLySKJ7j0r/fd0e804720e293fda0d1c9c2f1026740/sso-data-model)

Our `Users` and `Projects` tables do not change, but the relationships evolve to include our external identity providers.

For our Federated SSO implementation, we're going to implement an _Identifier-first_ login prompt. Our application will only ask for an email address for the user:

![SSO Login Prompt](https://images.ctfassets.net/23aumh6u8s0i/5uaqLWmRI3n3Z0TKysWTcg/dfb0e87190ced85da967c708cb216f31/sso-login-prompt)

The point of this is to look up the SSO identity provider associated with this email address, which in this case is **_cotoso.com_**, so the user will be redirected there to log in.

![SSO Flow](https://images.ctfassets.net/23aumh6u8s0i/4ovSoo6JhxjhQnaDBYNRcv/b1a5209e2608147b29e1cfd70fe7b5cc/sso-flow)

As shown in the image above:  once the user _(sally@contoso.com)_ enters her email address, our application determines that _contoso.com_ is our Identity Provider and redirects her there. Sally then logs into her _contoso.com_ corporate account, and _contoso.com_ verifies it. She is then redirected back to our application with access granted.

As part of this OpenID Connect authentication response, the `code` returned in the OpenID Connect Auth Response above is exchanged for an `ID Token`. The `ID Token` is what conveys the identity information from _contoso.com_ to our application, and looks like this:

``` json
{
  "iss": "https://id.contoso.com",
  "sub": "2482899761001",
  "name": "Sally",
  "email": "sally@contoso.com"
}
```

As with all ID Tokens, there is an _Issuer_ and an _Identifier_.  The Issuer being `https://id.contoso.com`, and the _Identifier_ being the subject `"sub": "2482899761001"`. In the auth flow above, our application (acme.com) will now look at this ID Token, identify Sally, and forward her onto our Dashboard, setting a Session Cookie for future requests.

From a database point-of-view, this SSO flow will look like this:

![SSO Database Flow](https://images.ctfassets.net/23aumh6u8s0i/3l5n9ubTlVC3BL9zbbmZJe/7d8aeb7f309d3477d96a3313d9b47748/sso-database-flow)

Firstly, our application will perform a lookup for the identity provider _contoso.com_, and redirect Sally to that login. Once Sally has logged in on _contoso.com_ and has been redirected back to our application, one of two things will happen. If Sally has never registered with our application before, a User record will be created for her, with the information returned from _contoso.com_. This would replace the sign up step we implemented in the basic example above. Our application will then associate the external identity with the new user record for find operations on subsequent logins.

![SSO Final Step](https://images.ctfassets.net/23aumh6u8s0i/20d076SSRPax813EDFIfYO/3f23fac0b59109b8a9d04c8a68faeb46/sso-final-step)

Similar to our earlier basic example, upon successful login, a _Session Cookie_ is set to portray the information required for subsequent requests.

With the above, we now have Single Sign On implemented on our acme.com sample application. Worth noting here is that in this SSO implementation, we have chosen an identifier-first login prompt with no option for a password. In reality, we would need to implement a password option for users that have existing non-federated accounts. Beside this, we should also implement a SAML integration, and support for account linking an unlinking.

By choosing to use an IDaaS provider like _Auth0_, we can get all of these features, plus many more straight out of the box.  Using [Auth0 for SSO](https://auth0.com/single-sign-on) allows us configuration of any enterprise connection, including Active Directory, LDAP, ADFS, SAML, and more with just a few lines of code.


## API Authorization
For the final implementation example of this article, we're going to look at API Authorization. We need to implement API auth so that our customers can integrate our service into their applications in ways not offered as standard, and to allow them deeper integrations. Once again, let's take a look at our data model, now including API auth:

![API Auth Model](https://images.ctfassets.net/23aumh6u8s0i/4NRyLQsRvkuyFmq64xuNeN/d0b5238abf314ac3f4051da5db971a17/api-auth-model)

Although the model now looks slightly more complex, following our aforementioned constraint; our `Users` and `Projects` schemas have not been changed. The schemas for SSO providers have not changed either. What has changed are the tables on the left, which introduce support for other people getting access to _Acme's_ APIs. If you are familiar with Facebook sign-on or GitHub etc, the terms above are fairly typical. `Clients` are the applications a user may build/use to access APIs and services, `Resource Servers` are the APIs themselves, and the Authorization Grants `(AuthZ Grants)` track the permissions that have been granted between the users and the applications.

For our API Authorization example, we are going to imagine that our sample company (Acme.com) have a customer named _Fabrikam.com,_ who wish to allow their customers to pull a list of their `Projects` from the _Acme_ API to display on their own dashboard.

From a simple button on the _Fabrikam.com_ website, their customers will be redirected through an OAuth2 Authorization request to the _Acme_ website, returning an Auth code on successful submission. Using the OAuth2 auth flow of [Client Credentials Grant](https://auth0.com/docs/api-auth/tutorials/client-credentials), this Auth code will then be swapped for an **Access Token** and used in the web application's _Authorization Header_ using the `Bearer` protocol.

Let's take a look at how the API Auth flow works visually:

![API Auth Login](https://images.ctfassets.net/23aumh6u8s0i/49pbvFGduF9VwuFevWGf66/e5c9bc8dc3632dbb826ff32e02b5cb46/api-auth-login)

As you can see from the image above, the customer of _Fabrikam.com_ clicks on the 'Connect to Acme' button on their Dashboard.  This click then issues a GET request to the `/connect/acme` route, which from the back end initiates an OAuth2 request to the _Acme.com_ server. The _Fabrikam.com_ customer is then prompted to log in using their _Acme_ credentials. On success, the _Acme.com_ server issues the OAuth2 Authorization Response to the `callback_url` specified in the initial request. In a similar manner to the _OpenID Connect_ example above, this response contains a `code` that will be exchanged for an **Access Token:**

![API Auth Login Response](https://images.ctfassets.net/23aumh6u8s0i/36WBGudxJpP0g6U9RaRb32/0dfc5f2e368f90c40054592d672aabcb/api-auth-login-response)

Following the [Client Credentials Grant flow](https://auth0.com/docs/api-auth/tutorials/client-credentials), the _Fabrikam.com_ back end swaps the above code for the Access Token needed for subsequent API requests.  The Access Token returned will have the following appearance:

``` json
access_token = eYJ0eXAi0...

{
  "iss": "https://www.acme.com",
  "aud": "https://api.acme.com/v1/",
  "sub": "501",
  "scp": [ "read:projects" ]
}
```

This _Access Token_ is similar to the _ID Token_ shown in the previous example, but instead of just identifying the user, it is also responsible for allowing _Fabrikam_ to make API calls subsequent to this Authentication event happening. This Token contains _Acme_ as the issuer, the API route to be used, the `subject` referring to the user id of "502", and the request _permissions_ in the `scope`. With the _Access Token_ now available to _Fabrikam.com_, it is used with requests for the customer's `Projects` from the _Acme.com_ API.

![API Auth Authd Reqs](https://images.ctfassets.net/23aumh6u8s0i/59HhtjSyKjTQST9ItgwwoL/8e3d373768fb5cfcb94297f2395ff731/api-auth-authd-reqs)

As the image shows, _Fabrikam_ sends the encoded token in the `Authorization` Header of the request, using the `Bearer` protocol, in all subsequent API requests.  The _Acme.com_ API successfully returns the customer's `Projects` which are listed in the Dashboard, as shown. That brings to a close the OAuth2 Client Credentials grant for API Auth example. However, we can take this a step further still. What if we wanted to combine this API Auth with the Enterprise SSO implementation in our previous example?

There may arise a scenario in which  _Fabrikam.com_ want to integrate with _Acme's_ APIs, but a user at _Acme_ authenticates with corporate credentials for _Contoso.com_ (who is an enterprise customer) as within our previous example. The flow becomes a multi-step process, with the first request coming from _Fabrikam_ to _Acme_, then _Acme_ to _Contoso_, with the responses flowing back in the opposite direction, back to _Fabrikam._. The interesting point of this scenario is that _Acme_ is acting as both an Identity Provider (when providing API authorization), and a Relying Party (when it's consuming identity information). This pattern may sound complex, but it is a very common scenario. Most SaaS companies both provide services, as well as authenticating users from other companies, meaning they have to implement both sides of the protocol (client and provider). The following diagram shows this implementation layout:

![OAuth OpenID Combine](https://images.ctfassets.net/23aumh6u8s0i/6WZAjqTn3OMo2eRyuLgvCS/1d678ed2c67c51061ddb1dfbb8773e90/oauth-openid-combine)

<include src="TweetQuote" quoteText="OAuth 2.0 and OpenID Connect have the same protocols because OpenID Connect is just an extension of OAuth."/>

Happily, as you will have noticed throughout this article, OAuth 2.0 and OpenID Connect have the same protocols, because OpenID Connect is just an extension of OAuth. This saves us a lot of hassle on implementation. At this point, with Authentication becoming a more prominent feature, it might be worth setting up a single, centralized server to handle all of the Auth requests coming through our app _(Acme)_.

If we revisit our data model, we can see that all of the tables in our model, except for the `Projects` table, can be treated as a separate concern, and become our authentication server:

![API Auth Model Pattern](https://images.ctfassets.net/23aumh6u8s0i/6jcNbD9NpTsH1E5Z9JcNtL/fd08c21e843f5af8e3944886aa3047af/api-auth-model-pattern)

We can take advantage of this in our architecture by creating the aforementioned centralized Auth server on a subdomain such as `id.acme.com`, and piping all of our Authorization / Authentication requests through there. The applications authenticating and being granted authorization through this centralized server may be third-party applications, such as _Fabrikam.com_ or _Contoso.com_, but also internal applications such as `app.acme.com`. Setting up this single centralized server is a nice and clean way to solve a lot of Auth challenges, with a single protocol and a single implementation. The architecture for this server could look like the following:

![Centralized Auth Server](https://images.ctfassets.net/23aumh6u8s0i/2hj6ZSI6wVtHmguWHPlEHq/8180c2f0e4abff657db1f05cb9536ecb/centralised-auth-server)

So with this, we have a fully functional OAuth 2.0 server implementation. Whilst this implementation is entirely functional, there are a few extra features not included in this example, that you would want to implement in the real world. One of the biggest is a _Consent Prompt_ ensuring users have the options of granting the application access, such as the following:

![OAuth2.0 Consent Prompt](https://images.ctfassets.net/23aumh6u8s0i/71FwyIRzi8zepAO1e0g4fu/388e0dfbe33ab932a3467b5e7fc3b142/consent-screen)

Besides this, consent and token revocation is also a must-have feature that would need implementing. Lastly, token introspection and JWTs for stateless authorization are both desirable features one would ideally implement.

If you wanted a fully-featured OAuth 2.0 server with all of the functionality mentioned above, it is definitely worth checking out an IDaaS provider to save you all of the implementation hassles. [Auth0](https://auth0.com/docs/protocols/oauth2) offers out of the box, fully featured OAuth 2.0 implementations that take care of all of the architecture above, plus offer more features and functionality; and all implemented without having to build and manage it yourself.



<include src="asides/AboutAuth0" />


3 IAM Examples to Support Digital Transformation

golo-roden

Guest Author

Golo Roden

Learn to build real-time web applications using wolkenkit and how to add authentication to them.

Building Real-Time Web Applications using wolkenkit

df6c864847fba9687d962cb80b482764?size=200 avatar

df6c864847fba9687d962cb80b482764?size=200

Martin Gontovnikas, a.k.a Gonto, is a software engineer at heart who moved to the ‘dark side’ and became VP of Marketing at Auth0. He considers himself lucky to have found a way to combine his two passions and apply his engineering thinking model to marketing.<br/><br/> Gonto’s analytical thinking is a huge driver of his data-driven approach to marketing strategy and experimental design. He is based in the Bay area, and in his spare time, can be found eating gourmet food at the best new restaurants, visiting every local brewery he can find, or traveling the globe in search of new experiences.

Former SVP of Marketing and Growth at Auth0

Martin Gontovnikas

Auth0 makes it simple and easy to add authentication and authorization to any app. By localizing our marketing website, we hope to make it easier for developers and companies to implement and see the benefits of modern identity management.



**BELLEVUE, WA - Konnichiwa!** We are pleased to announce that the Auth0 marketing website has been localized for the Japanese market. Auth0 makes it simple and easy to add authentication and authorization to any app with its powerful API and SDK’s for most languages and frameworks. 

Auth0 has always championed and embraced open-source software and we hope that by localizing our vast knowledge of security best practices we can make it easier for developers and companies, regardless of industry, location, or *language*, to make the web a safer and more secure place for everyone.

![Auth0 Japan](https://images.ctfassets.net/23aumh6u8s0i/7iYJ6F6NCYo6rYEaMi42b7/a7e02e6cc8b91a632cbd34e9a3a3486a/auth0-jp)

If you are visiting the Auth0 website from a Japanese locale, you will automatically see the website presented in Japanese. If you wish to view the Japanese version of the website but are outside of the Japanese locale, you can view it by visiting [https://auth0.com/jp](https://auth0.com/jp).

<include src="asides/AboutAuth0" />


The Auth0 Marketing Website Has Been Localized for the Japanese Market

Username and password are not enough. So why do most companies still use them?



<div class="alert alert-info alert-icon">
  <i class="icon-budicon-500"></i>
  <strong>Forrester Consulting analysis determines that using Auth0 can yield a 548% ROI and $3.7M in identity-related savings. Read the full report: <a href="https://resources.auth0.com/forrester-tei-research-case-study/">Total Economic Impact of Auth0</a>.</strong>
</div>

---

There’s a Technology Basics White Paper first published in 2002 entitled *“Username and Password – A Dying Security Model.”* This paper documents the **HIGH** risk level associated with legacy authentication (using username and password) and predicted that secure access methods using *Biometrics*, [*Single Sign On (SSO)*](https://auth0.com/learn/how-to-implement-single-sign-on/), [*One Time Password Tokens* (a.k.a *passwordless*)](https://auth0.com/passwordless) and [*Multi-Factor Authentication*](https://auth0.com/multifactor-authentication), would quickly replace the use of traditional passwords.

Fast forward to a decade and a half later and the majority of companies are still using username and password authentication. We all agree that legacy authentication is not good enough, so why do most companies still use them?


For many, the path to modern authentication seems difficult and expensive, while others worry about the impact on user experience.


Join me and Garrett Bekker (*Principal Security Analyst of 451 Research*) for a webinar where we will explore this paradox and discuss practices for making secure, modern authentication fast and easy for developers and simple and frictionless for users.

![Risks Posed By Legacy Authentication Webinar](https://images.ctfassets.net/23aumh6u8s0i/725zV9pN6ilKOKGJykmkiL/d6d69f5319e0bcfcff169f50c273574f/webinar-banner)

> The Webinar will be live online Jan 18 9:00 am PST or after on demand.

[Register now!](https://www.brighttalk.com/webcast/10363/235469?utm_source=Marketing&utm_medium=brighttalk&utm_campaign=235469)


Risks Posed By Legacy Authentication Webinar

d5365965372e0c5843d836f660b51a84?size=200 avatar

d5365965372e0c5843d836f660b51a84?size=200

Jeff Smith

Using JWTs to authenticate your React Native app will help it to be both secure and easy to integrate with a variety of services.

Adding Authentication to Your React Native App Using JSON Web Tokens

6c0654e56c8c73ffee8f76fe03d18ccf?s=80 avatar

6c0654e56c8c73ffee8f76fe03d18ccf?s=80

Alex Sears

JSON Web Tokens (JWT) provide an easy way to add authentication to Ruby apps. Learn all about how to secure your Rack API!



Early on in my career, when I was a wee little junior dev, learning Ruby on Rails and looking to impress, I came across an issue that is all too common these days. How do I authenticate a request with an API when the consuming client is a browser? This is a problem that will need to be solved if you are building a single page application.  At the time, I thought a single numeric "API token" that was returned to the user when they logged in was enough. Looking back, I realize how dumb of a move this was. It's extremely insecure!

Recently, I have been reading that [JSON Web Tokens](https://auth0.com/learn/json-web-tokens/) (also written as JWTs and pronounced "jots") are the way to go when authenticating with an API. If you haven't heard of JWTs, check out [the website](https://jwt.io/) and [read this blog post on using them with APIs](https://auth0.com/blog/2014/12/02/using-json-web-tokens-as-api-keys/). They make authenticating a user securely very easy.

Today, we are going to explore using JWTs in a Ruby environment, specifically with Rack apps. This includes Rails and Sinatra applications. Let's get to it! Create a new directory for this project and move into it.

```
mkdir ruby-jwt-api
cd ruby-jwt-api
```

First, let's setup the basic API itself. Create a `Gemfile` with the following in it.

```
source "https://rubygems.org"

gem 'sinatra'
gem 'jwt'
gem 'json'
```

Then, run `bundle`. If you don't already have bundler installed, run `gem install bundler`. This will install the dependencies we need. Next we need to create our `config.ru` file to run our Sinatra application.  Put the following in a file called `config.ru`.

```
require File.expand_path '../main.rb', __FILE__

run Rack::URLMap.new({
  '/' => Public,
  '/api' => Api
})
```

Here we are loading a file called `main.rb` and then setting up a new Rack application and running it. We create the application this way so we can put our JWT protection on only the API routes and not the public routes. We are loading the file, but we haven't created it yet! Let's do that. Create a file called `main.rb` and put the following in it.

```
require 'json'
require 'jwt'
require 'sinatra/base'

class Api < Sinatra::Base

  def initialize
    super

    @accounts = {
      tomdelonge: 10000,
      markhoppus: 50000,
      travisbarker: 1000000000
    }
  end

  get '/money' do
    content_type :json
    { message: "Hello, World!" }.to_json
  end
end

class Public < Sinatra::Base

  def initialize
    super

    @logins = {
      tomdelonge: 'allthesmallthings',
      markhoppus: 'therockshow',
      travisbarker: 'whatsmyageagain'
    }
  end

  post '/login' do
    username = params[:username]
    password = params[:password]

    if @logins[username.to_sym] == password
      content_type :json
      { message: "You logged in. Yay you!" }.to_json
    else
      halt 401
    end
  end

end
```

This code sets up our two application routes. The only public route we have right now is `/login`. It authenticates a user based on a username and password. Currently, it just returns a confirmation message. This is where we will eventually return a JWT the user can use to authenticate with the API. The API only has one route for now also called `/money`. It returns a simple message now too. Notice, we have hardcoded the values for our users. Normally this would come from a database of some sort.

Run `rackup` on the command line to start the server. Here are what our responses look like if we hit each of these endpoints. We hit the login route and get a success...

![First successful hit to the server endpoint](https://images.ctfassets.net/23aumh6u8s0i/37oTdL3zyegFb024TeBDxY/9104f52d64e6fdf6f46e1a05f75a075e/first_successful_hit)

...hit the login route and get an error...

![First unsuccessful hit to the server endpoint](https://images.ctfassets.net/23aumh6u8s0i/7E72SbsOBfnwiv74PxQNWo/74cc17454812ac79cfbb64ee310dea60/first_unsuccessful_hit)

...and hit the `/api/money` route to make sure our routing works correctly.

![First Successful API Hit](https://images.ctfassets.net/23aumh6u8s0i/5mSTx6nuOTca2kOHhVY1EF/a0f1d9f115419ea560f24dadc16d322b/first_successful_api_hit)

Now that we know our endpoints are working, let's add authentication and authorization using JWTs. We need to make sure that when we log our user in, we return a JWT so the user can use it to authenticate in the future.

```
post '/login' do
  username = params[:username]
  password = params[:password]

  if @logins[username.to_sym] == password
    content_type :json
    { token: token(username) }.to_json
  else
    halt 401
  end
end

def token username
  JWT.encode payload(username), ENV['JWT_SECRET'], 'HS256'
end

def payload username
  {
    exp: Time.now.to_i + 60 * 60,
    iat: Time.now.to_i,
    iss: ENV['JWT_ISSUER'],
    scopes: ['add_money', 'remove_money', 'view_money'],
    user: {
      username: username
    }
  }
end
```

Let's analyze this. We have changed what happens on a successful login. We set the content type to JSON and then return a Hash that has the token in it.

The token is generated by calling the `token` method and passing it the username. `token` uses [the jwt gem](https://github.com/jwt/ruby-jwt) to create an encoded JWT. It takes the payload, the secret, and the algorithm we want to use to sign the token. Our `token` method calls another method we created called `payload` which simply returns a Hash that contains all the data we want in our token payload.

Some things to note about the payload. It has an expiration date, which will be verified later. We also give it an issuer that we can verify later, a set of scopes that this token allows a user to do, and some data about our user. A sample response would look like this.

Restart your server. Make sure to pass the environment variables to it when you run it like so.

```
JWT_SECRET=someawesomesecret JWT_ISSUER=moneyapi.com rackup
```

![Retrieving a Successful JSON Web Token](https://images.ctfassets.net/23aumh6u8s0i/53TJSyy6aNrVQ0HE46bSZI/14262f5c738be70af3d1b76438bdd223/successful_token)

We have our first token! Yay! Notice how I have passed two environment variables on the command line. It's a good practice to pass these sorts of values in environment variables to avoid hardcoding them in our source code. These variables are used when creating (and later validating) our tokens.

Now we need to create a piece of middleware that will validate our token and then add the scopes and user data from the token to the request environment. This will allow us to access this information in our API routes. Add the following to our `main.rb` file.

```
class JwtAuth

  def initialize app
    @app = app
  end

  def call env
    begin
      options = { algorithm: 'HS256', iss: ENV['JWT_ISSUER'] }
      bearer = env.fetch('HTTP_AUTHORIZATION', '').slice(7..-1)
      payload, header = JWT.decode bearer, ENV['JWT_SECRET'], true, options

      env[:scopes] = payload['scopes']
      env[:user] = payload['user']

      @app.call env
    rescue JWT::DecodeError
      [401, { 'Content-Type' => 'text/plain' }, ['A token must be passed.']]
    rescue JWT::ExpiredSignature
      [403, { 'Content-Type' => 'text/plain' }, ['The token has expired.']]
    rescue JWT::InvalidIssuerError
      [403, { 'Content-Type' => 'text/plain' }, ['The token does not have a valid issuer.']]
    rescue JWT::InvalidIatError
      [403, { 'Content-Type' => 'text/plain' }, ['The token does not have a valid "issued at" time.']]
    end
  end

end
```

This is a simple Rack middleware setup. In the `call` method, we get the `HTTP_AUTHORIZATION` value out of the environment hash, which represents the `Authorization` header in the request.  We use `fetch` so we get a string if `HTTP_AUTHORIZATION` doesn't exist and then use `slice` to prevent throwing an error if the string indexes we want don't exist. This will strip off the "Bearer: " part of the `Authorization` header. We then decode the JWT and add the scopes and user data to the environment hash. Lastly, we call the next part in our middleware stack and pass it our modified environment.

We have wrapped this code in a `begin, rescue`. This is because the `jwt` gem will throw different exceptions for each thing that may be wrong with it, such as the validation not passing. We catch each one and return a good error message for it.

Now that we have the data available on our request environment, let's use it in our API route.

```
class Api < Sinatra::Base

  use JwtAuth

  def initialize
    super

    @accounts = {
      tomdelonge: 10000,
      markhoppus: 50000,
      travisbarker: 1000000000
    }
  end

  get '/money' do
    scopes, user = request.env.values_at :scopes, :user
    username = user['username'].to_sym

    if scopes.include?('view_money') && @accounts.has_key?(username)
      content_type :json
      { money: @accounts[username] }.to_json
    else
      halt 403
    end
  end

end
```

Here, we initialize the class with some data, like we did with the `Public` class. Notice we `use JwtAuth` in this class. This is our way of including our token authentication middleware. This causes it to be run before the routes on this class are run. We then setup a `/money` route. This route grabs the scopes and user out of the environment. It then gets the username out of the user data. It checks to make sure this token has the `view_money` scope and that the username is a valid one in the data we have. If all this checks out, it returns the amount of money in the account. That's all there is to it.

![Hiting the Get Money route](https://images.ctfassets.net/23aumh6u8s0i/2hmmyaWekQu2TTSqsagON2/0ca839945394450177cb232ffa92bb9b/get_money)

We can use this same setup to add and remove money from these accounts.

```
post '/money' do
  scopes, user = request.env.values_at :scopes, :user
  username = user['username'].to_sym

  if scopes.include?('add_money') && @accounts.has_key?(username)
    amount = request[:amount]
    @accounts[username] += amount.to_i

    content_type :json
    { money: @accounts[username] }.to_json
  else
    halt 403
  end
end

delete '/money' do
  scopes, user = request.env.values_at :scopes, :user
  username = user['username'].to_sym

  if scopes.include?('remove_money') && @accounts.has_key?(username)
    amount = request[:amount]

    @accounts[username] -= amount.to_i
    if @accounts[username] < 0
      @accounts[username] = 0
    end

    content_type :json
    { money: @accounts[username] }.to_json
  else
    halt 403
  end
end
```

Here we are doing similar work as the previous route except we are sending `POST` and `DELETE` requests to add and remove money.  Our output would look like this when adding money...

![Adding Money using the API endpoint](https://images.ctfassets.net/23aumh6u8s0i/6cREs0pHtL5ghb0aT9QHMc/5c45ddd136e86614f197c0427bc3f501/add_money)

...and when removing money.

![Deleting Money using the API endpoint](https://images.ctfassets.net/23aumh6u8s0i/4AGDt3bC0dQJGI3PyRpD5F/94877eba401879712cac3e1765c5d579/delete_money)

As you can see, we can now use JWTs to add and remove money also. You may have noticed that we have some duplicated code here though. That's not good when we can prevent it! Luckily, we can. We can refactor our code like so.

```
get '/money' do
  process_request request, 'view_money' do |req, username|
    content_type :json
    { money: @accounts[username] }.to_json
  end
end

post '/money' do
  process_request request, 'add_money' do |req, username|
    amount = req[:amount]
    @accounts[username] += amount.to_i

    content_type :json
    { money: @accounts[username] }.to_json
  end
end

delete '/money' do
  process_request request, 'remove_money' do |req, username|
    amount = request[:amount]

    @accounts[username] -= amount.to_i
    if @accounts[username] < 0
      @accounts[username] = 0
    end

    content_type :json
    { money: @accounts[username] }.to_json
  end
end

def process_request req, scope
  scopes, user = req.env.values_at :scopes, :user
  username = user['username'].to_sym

  if scopes.include?(scope) && @accounts.has_key?(username)
    yield req, username
  else
    halt 403
  end
end
```

We have extracted the common code out into its own method and pass in the functionality for each route into the `process_request` method as a block.

That's all there is to it. We can now use our `JwtAuth` middleware anywhere we want to protect routes with JSON web tokens.

![Drop the mic](https://images.ctfassets.net/23aumh6u8s0i/71PTFQvHyCb4tSTO4bUwr8/611c9310a6b1713a01992f3eb6a2a142/giphy)

## What about Auth0?

[Auth0](https://auth0.com/) handles all this business of authenticating your users and creating JWTs so you can concentrate on building your application. There's even [a gem](https://github.com/auth0/ruby-auth0) that makes interacting with the Auth0 API so much easier. Let them handle the boring authentication while you build the next MyFaceTwiSterGram.

Wanna integrate Auth0 with RoR? Simple. The excellent writers over at Auth0 have you covered. They have written [extensive documentation](https://auth0.com/docs/quickstart/webapp/rails/) on how to do just that. It goes a little something like this.

### Add Omniauth and Auth0's strategy

Add the following to your `Gemfile` and run `bundle install`.

```
gem 'omniauth', '~> 1.3'
gem 'omniauth-auth0', '~> 1.4'
```

### Initialize Omniauth

Put the following in a file at `config/initializers/auth0.rb`, replacing the ALL_CAPS values with their actual values received when creating an application on the Auth0 dashboard.

```
Rails.application.config.middleware.use OmniAuth::Builder do
  provider(
    :auth0,
    'YOUR_CLIENT_ID',
    'YOUR_CLIENT_SECRET',
    'YOUR_NAMESPACE',
    callback_path: "/auth/auth0/callback"
  )
end
```

### Add the callback handler for Auth0

Use this command to create a controller to handle the Auth0 callback.

```
rails generate controller auth0 callback failure --skip-template-engine --skip-assets
```

In this newly-created file, add the logic to handle the success and failure of the callback.

```
class Auth0Controller < ApplicationController
  def callback
    # This stores all the user information that came from Auth0
    # and the IdP
    session[:userinfo] = request.env['omniauth.auth']

    # Redirect to the URL you want after successfull auth
    redirect_to '/dashboard'
  end

  def failure
    # show a failure page or redirect to an error page
    @error_msg = request.params['message']
  end
end
```

Also, replace the routes we created earlier with the following ones instead.

```
get "/auth/auth0/callback" => "auth0#callback"
get "/auth/failure" => "auth0#failure"
```

### Add the callback to Auth0's dashboard

You need to make sure you add the callback URL to the [Application Settings](https://manage.auth0.com/#/applications) in the Auth0 dashboard area.

For example, the callbacks we have created will be reached at `http://yourUrl/auth/auth0/callback`.

### Pick a method of triggering the login

There are multiple ways you can trigger the login flow in your application. For example, you could use the Auth0 Lock widget, Passwordless, or some custom UI. Here is what the code would look like to use the Lock widget in modal form.

```html
  <script src=“https://cdn.auth0.com/js/lock/10.0/lock.min.js"></script>
  <script type="text/javascript">

    var lock = new Auth0Lock('YOUR_CLIENT_ID', 'YOUR_NAMESPACE');


    function signin() {
      lock.show({
        callbackURL: '',
        responseType: 'code',
        authParams: {
          scope: 'openid email'  // Learn about scopes: https://auth0.com/docs/scopes
        }
      });
    }
  </script>
  <button onclick="window.signin();">Login</button>
```

### Accessing User Info

Once all this is setup, you can access user information like you normally would when using the Omniauth gem and its provider gems.

```ruby
class DashboardController < SecuredController
  def show
    @user = session[:userinfo]
  end
end
```

```html
  <div>
    <img class="avatar" src="<%= @user[:info][:image] %/>"/>
    <h2>Welcome <%= @user[:info][:name] %></h2>
  </div>
```

This is only a portion of the information you can get from their docs. [Head over there](https://auth0.com/docs/quickstart/webapp/rails) to get more information on integrating with Rails.

## Authentication is hard

Authentication in a web application can be difficult. However, whether you use Auth0 or roll your own solution, the `jwt` ruby gem offers a simple way to use JWTs in your ruby application. This allows stateless authentication that can be used in a traditional application or a decentralized API.

<include src="TweetQuote" quoteText="Authentication in a web application can be difficult. However, Auth0 simplifies it with JWTs."/>


Ruby Authentication: Secure Your Rack Application with JWT

ryan-chenkie

Ryan is a full-stack JavaScript developer and trainer who mainly works with React, Angular, Node, and GraphQL. He runs a consultancy where he builds apps for companies and also helps established dev teams with their modern JavaScript challenges.<br /><br />Ryan is a Google Developer Expert, the host of the Entrepreneurial Coder Podcast, the author of Securing Angular Applications, and an all-around fanatic about application security.

Developer

Ryan Chenkie

Learn how to implement a simple REST API with JWT Authentication in Rust using the Nickel.rs web framework and the MongoDB Rust Driver.

Build an API in Rust with JWT Authentication using Nickel.rs

Conventional authentication is challenging for today's web applications. Learn about the reasons and how to use JSON Web Tokens (JWT) for modern authentication.



---

**TL;DR:** Traditional session-based authentication with cookies presents difficulties, especially for modern web applications. We can instead use JSON Web Tokens (JWT), which make our apps stateless. Migrating a legacy app over to JWT authentication can be done piece by piece, and if we need to, we can use cookies to handle JWTs. To see how this is done, take a look at the [repo](https://github.com/auth0/cookie-jwt-auth) for this tutorial.

---
Authentication for web applications has historically been fairly straightforward and followed a common pattern, but this has been changing significantly in recent years. There are several reasons for these changes, and the prominent ones are related to the way in which modern applications are built and distributed.  In this article, we'll see how things have changed and also some ways we can adapt legacy applications to modern day practices.

## Traditional Web Applications

In a general sense, traditional websites and applications typically implement user authentication using **sessions** and **cookies**. When users log in to a site, their username and password are matched against database entries. If the login is successful, the server saves the user's authentication state in memory and sends a cookie back in the response that contains some data, which in most cases includes the user's ID. Browsers will save the cookie for the domain from which it came and then automatically send it back when subsequent requests are made. For example, if a cookie is saved with a domain of auth0.com, it will be sent back on any future request to auth0.com as long as it is valid. This works great for traditional web apps.

![modern authentication jwt](https://images.ctfassets.net/23aumh6u8s0i/2E0gj0N91SqR18iJcYX0pS/2843825e62cc48a85c287ffad235efc9/legacy-app-auth-1)

Even though we've labeled the process described above as being "traditional", it should be noted that *most* of the web still operates this way. While this approach is still perfectly valid for a lot of use cases, we're going to explore some of the reasons why relying on it has become challenging for modern web applications.

## Authentication Challenges for Modern Web Apps

Modern web applications present a few challenges for authentication that are difficult to solve using conventional methods. The reasons for this have to do with how applications are crafted and the environment in which applications reside.

### 1. Apps are distributed across many servers

Many of today's applications aren't deployed the same way they were in the past. It is now very common--and often necessary--for apps to be distributed across many servers so that up-time is increased and latency issues are mitigated. With this comes the side effect that, when a user accesses an application, it is no longer guaranteed that they are always accessing the same server.

Since traditional authentication relies on the server to keep the user's authentication state in memory, things break down when the app is accessed from different servers. The user might be logged in on one server but not on the others that the application is distributed across.

We can get around this by using methods like [**sticky sessions**](http://stackoverflow.com/questions/10494431/sticky-and-non-sticky-sessions). A sticky session will essentially route the user to the server instance from which they logged in so that the authentication state can be presevered. This type of workaround will do the job, but as we'll see, stateful servers in general don't play that well with modern applications.

### 2. Apps use APIs for data

A common pattern for modern applications, especially single-page apps, is to retrieve and consume JSON data from a [RESTful API](http://www.restapitutorial.com/). Serving data from an API has several distinct advantages, one of them being the ability for data to be used in more than just one application. For example, an organization might start with the intent to build an internally facing application, but may soon realize that some of its functionality could be used in a public-facing app. Down the road, the organization might also decide that some of its data should be accessible by other application developers to build third-party apps with. This can all be made possible with an API.

Using APIs in this fashion is great, but things can become challenging when it comes to authentication. The traditional approach of using sessions and cookies for the user's identity doesn't work so well in these cases because their use introduces **state** to the application. One of the tenets of a RESTful API is that it should be **stateless**, meaning that, when a request is made, a response within certain parameters can always be anticipated without side effects. A user's authentication state introduces such a side effect, which breaks this principle. Keeping the API stateless and therefore without side effect means that maintainability and debugging are made much easier.

<include src="TweetQuote" quoteText="Keeping the API stateless means that maintainability and debugging are made much easier."/>

Another challenge here is that it is quite common for an API to be served from one server and for the actual application to consume it from another. To make this happen, we need to enable [Cross-Origin Resource Sharing (CORS)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS). Since cookies can only be used for the domain from which they originated, they aren't much help for APIs on different domains than the application.

### 3. Apps rely on downstream services

Another common pattern seen with modern web applications is that they often rely on downstream services. For example, a call to the main application server might make a request to a downstream server before the original request is resolved. The issue here is that cookies don't "flow" easily to the downstream servers and can't tell those servers about the user's authentication state. Since each server has its own scheme for cookies, there is a lot of resistance to flow, and connecting to them is difficult.

## A Modern Alternative: The JSON Web Token (JWT)

To combat the issues detailed above, we can take a token-based approach by using JSON Web Tokens (JWTs) for authentication. A JWT contains three parts:

**1. Header**

The header tells us about the algorithm and token type. It is Base64URL encoded.

**2. Payload**

The payload contains any arbitrary information in the form of claims that we as developers find useful for our applications. The user's ID must be sent as a `sub` claim, but we can also send other useful information, such as the username, email, and more. The payload is also Base64URL encoded.

**3. Signature**

The signature is used to verify the authenticity of the JWT. There are several different algorithms that can be used for the signature. Some algorithms implement a shared secret (HMAC), and others use public-private key secrets (RSA).

![modern authentication jwt](https://images.ctfassets.net/23aumh6u8s0i/1sS3oSviChEPzlXMAYHHLQ/b58c9c25c3ecb38505a5e77e5965e981/legacy-app-auth-5)

From the user's perspective, logging in to an application that uses JWTs looks much like traditional authentication. Users enter their credentials as usual, but instead of the server creating a session and returning a cookie, it will respond with a JSON object that contains a JWT. The JWT then needs to be saved locally, which is normally done with local storage. However, as we'll see in the next section, it is possible to save the JWT in a cookie.

The JWT must be sent to the server to access protected routes, and it is typically sent as an `Authorization` header. The scheme used for this header is `Bearer`, so the full header looks like this:

```js
Authorization: Bearer <token>
```

Middleware on the protected API routes will check for a valid JWT, and if there is one, it will let the request through and return the data being requested. Since the user's information is contained within the JWT itself, there is no need to look the user up in a database, so there is less latency in the application.

It should be reiterated that the user's state is never saved in memory on the server, meaning that the user isn't "logged in" in the conventional sense. However, a valid JWT gives the user the keys to access data each time a request is made, and in this way, a stateless authentication mechanism is in place.

![](https://images.ctfassets.net/23aumh6u8s0i/1f37fJAPR7UgfFW8oYYeKs/5f00a4413b04510ad6bd6801f04a2fed/legacy-app-auth-2)

Using a JWT for authentication helps to solve the challenges noted above. We can fully rely on data APIs that are stateless and even make requests to downstream services. Since JWT is a specification [implemented nearly everywhere](http://jwt.io), connecting to downstream services built on a stack other than our own is easy. It also doesn't matter which domain is serving our API, nor does it matter which specific server a request goes to if the app is deployed across many.


## Bridging the Gap: Using JWTs in Cookies

Modernizing legacy applications by implementing token-based authentication can lead to many gains. If it isn't feasible for an organization to totally throw away cookies, there are still ways to make token authentication viable. Let's take a look at how this can be done with NodeJS and the **express-jwt** package.

### Step 1: Set Up a Back End

To follow along, you can download Auth0's NodeJS seed project from the [NodeJS Quickstart](https://auth0.com/docs/quickstart/backend/nodejs/). Even though we're using an Auth0 seed project here, doing cookie-based authentication in this way will work with any service.

### Step 2: Install Cookie Parser

Once the dependencies for the seed project are installed by following the [installation steps](https://github.com/auth0/node-auth0/tree/master/examples/nodejs-api), we'll need to add one more package: **cookie-parser**. This package will allow us to read JWTs from cookies that are sent to the server.

```bash
npm install cookie-parser --save
```

With **cookie-parser** installed, we now need to require and use it in `server.js`.

```js
// server.js

...

var cookieParser = require('cookie-parser');

...

app.configure(function() {

  app.use(cookieParser());

  ...

});
```

### Step 3: Save the JWT as a Cookie

We'll need to retrieve a JWT for a user and save it locally as a cookie. If you're using Auth0 for this tutorial, you can find out more about retrieving JWTs for users in your Auth0 account by reading the [API documentation](https://auth0.com/docs/api/v2). We'll use jQuery in this example to make the AJAX calls easy.

Lets make a call to Auth0 to get a JWT.

```js
// app.js

$('.btn-login').click(function() {
  $.ajax({
    type: 'POST',
    url: 'https://{your-auth0-account}.auth0.com/oauth/ro',
    data: {
      client_id: '{your-client-id}',
      username: document.querySelector('#username').value,
      password: document.querySelector('#password').value,
      grant_type: 'password',
      scope: 'openid',
      connection:'Username-Password-Authentication'
    },
    success: function(data) {
      getJwtCookie(data.id_token);
    },
    error: function(error) {
      console.log('There was an error: ' + error)
    }

  });
});
```

In the success handler, we're calling a function called `getJwtCookie` and passing in the token that was received from Auth0. We need to create an endpoint on our application server that can validate the JWT that was received from Auth0 and send it back to us as a cookie, and we can do that in the `getJwtCookie` function.

```js
// app.js

function getJwtCookie(token) {
  $.ajax({
    type: 'POST',
    url: 'http://localhost:3001/secured/authorize-cookie',
    data: {
      token: token
    },
    headers: {
      'Authorization' : 'Bearer ' + token
    },
    success: function() {
      console.log('Cookie received!');
    },
    error: function() {
      console.log('Problem with cookie');
    }
  });
}

```
Next, lets set up the `authorize-cookie` endpoint to handle this call.

```js
// server.js

app.post('/secured/authorize-cookie', authenticate, function(req, res) {
  res.cookie('id_token', req.body.token, {
    expires: new Date(Date.now() + 36000),
    httpOnly: true
  });
  res.send(200, { message: 'Cookie set!' });
});
```

In the next step, we'll set up our **express-jwt** middleware, but we're making use of it already in the `authorize-cookie` route by passing it in as the second argument, `authenticate`. The middleware secures the endpoint and a valid JWT will be needed to access it. If the JWT is valid, we simply reflect it back as a cookie and set the `httpOnly` flag to `true` so that the cookie can only be accessed by the server. This route accomplishes the steps of validating the JWT that was received from Auth0, as well as the step of setting a cookie with the JWT.

**Note:** We are using an `Authorization` header to accomplish our cookie JWT in this example. This is the only place we would need to make a request using this header--the rest of the application will handle JWTs with cookies.

### Step 4: Set Up Middleware to Check for the Cookie
Normally, the **express-jwt** middleware will look for the presence of a header and retrieve the JWT from there. However, we can also create a custom function to define how the token should be retrieved.

```js
// server.js

...

var authenticate = jwt({
  secret: new Buffer(process.env.AUTH0_CLIENT_SECRET, 'base64'),
  audience: process.env.AUTH0_CLIENT_ID,
  // Custom function to retrieve the JWT
  // We first look for the JWT in a header and if it isn't there,
  // we look for it in a cookie
  getToken: function fromHeaderOrCookie(req) {
    if(req.headers.authorization && req.headers.authorization.split(' ')[0] === 'Bearer') {
      return req.headers.authorization.split(' ')[1];
    } else if(req.cookies && req.cookies.id_token) {
      return req.cookies.id_token;
    }
    return null;
  }
});

...
```

We've added the `getToken` function as an option on the object that is passed into `jwt`. Our implementation here says that we want to first look for the presence of a JWT as an `Authorization` header, and if there isn't anything there, we want to check whether there is a cookie with the name `id_token`.

### Step 5: Test the Secured Route

With the `id_token` cookie in place, we can see that requests to the `secured/ping` endpoint go through just fine.

![modern authentication jwt](https://images.ctfassets.net/23aumh6u8s0i/4j5ZnQitsiwgVbLtwupT71/104a61fb2584f11a192c1fb36e476f92/legacy-app-auth-3)

<include src="asides/Jwt" />

## Wrapping Up

As we've seen, modern web applications are crafted and deployed in ways that make conventional user authentication challenging. JWT authentication is an excellent way to get around these challenges and allows us to keep our application server stateless. If we need to lean on old practices, such as using cookies, we can do so and still support JWT authentication with a little tweaking on the server.


5 Steps to Add Modern Authentication to Legacy Apps Using JWTs

bb9128fac91692ad4f46a785d772dd39?s=200 avatar

bb9128fac91692ad4f46a785d772dd39?s=200

Data Scientist and Engineer, I love tinkering with data!

Head of Data

Pablo Seibelt

Learn how to leverage Auth0 to have Shiny Authentication for the open source version or another legacy website.



<div class="alert alert-info alert-icon">
  <i class="icon-budicon-500"></i>
  <strong>Some content in this post is outdated. Check our <a href="https://auth0.com/blog/adding-authentication-to-shiny-server/">updated guide</a>.</strong>
</div>


[Shiny Server](https://www.rstudio.com/products/shiny/shiny-server/)  is a great solution for BI/analytics reporting. It leverages all the power of the [R language](https://www.r-project.org/), which is the most popular open-source language for statistics, and it has a lot of useful functions for *Data Mining*, *Machine Learning*, *Reporting*, etc.

<include src="TweetQuote" quoteText="Shiny Server is a great solution for BI/analytics reporting."/>

The open-source version of Shiny Server features no Authentication, and if it's open on Internet, it leaves your data exposed. In that case, you likely won't want everyone on the Internet to be able to see your internal analytics, so you'll need to install and configure the authentication yourself.

One of the easiest ways to add authentication to Shiny and, by extension, any unsecured web application, is to use Apache with Auth0 through the **auth_openidc** module.

This is also useful if you have a legacy web app with a username and password everyone shares or if you are hosting a server with static files you want to share.

![Diagram of the Shiny Authentication scheme](https://images.ctfassets.net/23aumh6u8s0i/1X0EfCJlUSk3CSdyrX73W5/be36fbf08b114b587aa265ebc73987a9/pub_w_959_h_638)

So, let's get started with the steps.

## Installing and Configuring Shiny

First, follow the instructions to [install and configure Shiny Server](https://www.rstudio.com/products/shiny/download-server/).

When you have installed and configured Shiny and you're sure it works, modify your config file so it only serves to 127.0.0.1 (the local machine). This ensures that we don't accidentally expose the open server to the entire Internet.

```
[...]
server {
  listen 3838 127.0.0.1;
[...]
```

## Installing Apache and the OpenID Connect Module

We will use Apache as a gateway to our app using [Auth0's tutorial](https://auth0.com/docs/server-platforms/apache). This will enable Apache to serve as a gatekeeper—a reverse proxy that only serves after authentication.

If you don't already have apache2 installed, install it according to your platform and ensure that you have two modules: mod_proxy and mod_auth_openidc.

mod_proxy is pretty standard. It comes with most apache2 installs, but it is often disabled. To enable it, execute the following with root:

```
a2enmod proxy_http
```

mod_auth_openidc is provided in Debian as libapache2-mod-auth-openidc. Binary packages are available at [the releases page](https://github.com/pingidentity/mod_auth_openidc/releases), or you can always [build it from source](https://github.com/pingidentity/mod_auth_openidc/blob/master/INSTALL). When it is installed, enable it with this command:

```
a2enmod auth_openidc
```

## Configure an Auth0 Account

If you don't already have an Auth0 Account, <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">create one here</a> and set up the type of connections you want to allow. The default settings allow anyone to sign up, but you can set up a better scheme. For example, if you use Google Apps, you can just connect that and [allow only those from your domain to access the server](https://manage.auth0.com/#/connections/enterprise). Alternatively, you can use [rules](https://manage.auth0.com/#/rules) to decide which users are allowed access.

You can [browse the docs](https://auth0.com/docs) or [ask for help](https://support.auth0.com) setting up the best scheme for your scenario.

## Configure Apache to Serve Shiny with Auth0

Make sure Shiny is running in the background while Apache tries to serve it. You can ensure that it's always on by [running it as a Daemon](https://rstudio.github.io/shiny-server/latest/#stopping-and-starting).

You will need to follow the steps in [the Apache tutorial](https://auth0.com/docs/server-platforms/apache). Note: when you are logged in to Auth0, the tutorial includes your own variables in the configuration to make it easier for you.

Create a configuration file for your website using the configuration from the tutorial as a starting point. Replace everything from OIDCProviderIssuer to Location with the code in the tutorial.

You will need to personalize your OIDCRedirectURI. I recommend using https://<your_apache_server>/auth. Of course, replace <your_apache_server> with the public address that will be used for your server.

You also need to generate or write some random string on <passwordToEncryptTheSessionInformationOnTheCookie>

You should at least have a [self-signed SSL certificate](https://devcenter.heroku.com/articles/ssl-certificate-self) to test and a real one to deploy.

It should look something like this:

```
<VirtualHost *:443>
  ProxyPass / http://localhost:3838/
  ProxyPassReverse / http://localhost:3838/
  ProxyPreserveHost On

  OIDCProviderIssuer https://<your-tenant>.auth0.com
  OIDCProviderAuthorizationEndpoint https://<your-tenant>.auth0.com/authorize
  OIDCProviderTokenEndpoint https://<your-tenant>.auth0.com/oauth/token
  OIDCProviderTokenEndpointAuth client_secret_post
  OIDCProviderUserInfoEndpoint https://<your-tenant>.auth0.com/userinfo

  OIDCClientID <YourClientID>
  OIDCClientSecret <YourClientSecret>

  OIDCScope "openid profile"
  OIDCRedirectURI https://<your-website>/auth
  OIDCCryptoPassphrase <passwordToEncryptTheSessionInformationOnTheCookie>
  OIDCCookiePath /

  SSLEngine on
  SSLCertificateFile /path/to/server.crt
  SSLCertificateKeyFile /path/to/server.key

  <Location />
     AuthType openid-connect
     Require valid-user
     LogLevel debug
  </Location>

</VirtualHost>
```

You can save it somewhere like ``/etc/apache/sites-available/001-shiny` and then link it to make it active:

```
ln -s /etc/apache/sites-available/001-shiny /etc/apache/sites-enabled/001-shiny
```

As the tutorial states, Auth0's `clientSecret` is by default Base64 encoded, which isn't compatible with this Apache plugin out of the box. We're going to change that in the near future, but in the meantime, you need to call an API to make sure the clientSecret isn't Base64 encoded for your account.

Get an access token by clicking "Try Me!" on the [docs page](https://auth0.com/docs/api/v1#!#post--oauth-token) and execute the code shown in step 3 of the tutorial to change `ACCESS_TOKEN` to the access token you just received.

## Boom.

Now you have a Shiny Server that is secured with Auth0, which you can use to serve reports only to employees of your organization using username and password authentication or [one of the many identity providers supported](https://auth0.com/docs/identityproviders).

This same configuration works well for other cases. For example, suppose you have an old legacy web application for which everyone uses the same password. That scenario is not very safe, is it? You can give it an additional security layer with the above approach without modifying your site.

## Gotchas

Shiny uses websockets for a lot of things. While we haven't explored tunneling, it is theoretically possible with **proxy_wstunnel**. For most users, this will work fine because if the library fails with websockets, it will automatically fall back to XHR.


"web authentication"