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

WebAuthn Authenticators offer a streamlined user experience and enhanced security

In the last few years, the [FIDO Alliance](https://fidoalliance.org/) has been working relentlessly towards the vision of helping users authenticate with maximum security and minimum friction. The resulting [WebAuthn standard](https://www.w3.org/TR/webauthn-1/) provides the foundation for that to happen. Now it is up to the industry to make that technology available to end users. 

WebAuthn is the only standard-based authentication method that makes phishing impossible, as it binds the public/private key to a specific web domain. You cannot mistakenly authenticate into a phishing website.

A few weeks ago, [we announced](https://auth0.com/blog/fido-security-key-support-comes-to-auth0/) the support for [FIDO Security Keys for MFA](https://auth0.com/docs/mfa/fido-authentication-with-webauthn) using WebAuthn. Security Keys are a great way to secure access to your account, but their adoption is mostly limited to tech-savvy users or corporate environments with relatively high-security requirements.

We are now announcing support for [**FIDO Device Biometrics for MFA using WebAuthn**](https://auth0.com/docs/mfa/fido-authentication-with-webauthn). This makes the security and convenience of WebAuthn-powered flows available to anybody who has a device and browser who can support the biometric challenge, not just those who have security keys. Now all users can reap the benefits of this technology, regardless of how tech-savvy they are. 

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

Enabling users to authenticate using their device biometrics has two benefits: it **greatly reduces friction** during the authentication challenge, which impacts user **retention and revenue**, and **it increases security** since the flow is not phishable by bad actors. 

The data we collected during Beta testing shows biometrics performing much better than other MFA options:

![Internal Auth0 study, March 2021](https://images.ctfassets.net/23aumh6u8s0i/wD2JeWObWymymRv7Xs7gf/8d5c021776667b1e87d691cf7429e37a/graphics.jpg)
<p align="center"><i>Internal Auth0 study, March 2021</i></p>
<br>

The Y axis shows time to complete, and the X axis represents the % of users that can complete the MFA challenge. WebAuthn platform authenticators have the highest passing rate (94%) and the shortest time to complete (5 seconds).

## WebAuthn With Device Biometrics Availability

For users to take advantage of biometric authentication on the web, they need to have devices that support WebAuthn. It’s hard to know precisely how many devices are capable of WebAuthn Device Biometrics, as there is no specific information. We can only approximate with operating system and browser usage statistics, as in Android and Windows, it depends on the device in addition to the OS/Browsers.

<table border="1">
<tbody>
<tr>
<td><b>Operating System & Browsers with WebAuthn Device Biometrics Support</b></td>
<td><b>OS Adoption March 2021 Source: <i>StatCounter</i></b></td>
</tr>
<tr>
<td>Mac OS Catalina (Chrome, Edge, Brave)</td>
<td><a href="https://gs.statcounter.com/os-version-market-share/macos/desktop/worldwide#monthly-202103-202103-bar">67%</a></td>
</tr>
<tr>
<td>Mac OS Big Sur (Chrome, Edge, Safari, Brave)</td>
<td>Unknown</td>
</tr>
<tr>
<td>iOS 14+ (Safari)</td>
<td><a href="https://gs.statcounter.com/os-version-market-share/ios/mobile-tablet/worldwide#monthly-202103-202103-bar">76.24%</a></td>
</tr>
<tr>
<td>Windows 10 + (All modern browsers)</td>
<td><a href="https://gs.statcounter.com/os-version-market-share/windows/desktop/worldwide#monthly-202103-202103-bar">78.28%</a></td>
</tr>
<tr>
<td>Android 7+ (Chrome)</td>
<td><a href="https://gs.statcounter.com/android-version-market-share/mobile-tablet/worldwide/#monthly-202103-202103-bar">82.08%</a></td>
</tr>
</tbody>
</table>
<br>

You can get additional information about browser support on our [webauth.me](https://webauthn.me/browser-support) site.

## Enrolling With Device Biometrics

Authenticating using WebAuthn with Device Biometrics presents two unique challenges:

* Given the authentication method is bound to a specific device, it cannot be **the only** authentication method the user has, or they will be unable to log in from a different device. 
* Users would want to use biometrics to login from all of their devices, and applications should make it possible to enroll all of them.

Auth0’s solution addresses both problems. It will always ensure that users’ have another way to authenticate. When MFA is enabled, users can only enable biometric authentication if they also enable another option.

The enrollment flow would be as follows:

![The enrollment flow](https://images.ctfassets.net/23aumh6u8s0i/skfRYpG6f4PbJAfT5jcji/98afcec8e1653c389b6344099a2ff003/unnamed-2.png)

* The user authenticates with a username and password.
* Enrolls in any other MFA Factor (e.g., a security key, a TOTP application like Google Authenticator, Push, SMS)
* If the device is capable of using Webauthn Device Biometrics, users will get the option of enrolling with it.
* If they do, the next time they login from that device, they can use Device Biometrics as the second factor.

#### Progressive Enrollment

Auth0 employs progressive enrollment to aid users in authenticating from different, WebAuthn-capable devices. Whenever a user presents this type of device for authentication, they will first be prompted to enroll it. This is a progressive process that is only activated once new, WebAuthn-capable devices are used so that they will be able to authenticate with biometrics in all of their devices capable of this functionality. 

For example, when a user initially authenticates from a MacBook with a Touchbar, they authenticate with their username and password and enroll in another MFA factor. However, since the MacBook has biometric capabilities, they will be prompted to enroll if they like. Later, if they wish to use their iPhone with FaceID capabilities, they will be automatically asked to use Face ID before proceeding. This process guides users through a progressive enrollment flow that is easy, seamless, and friction-free.

Here’s a quick demo of WebAuthn with Auth0:
<include src="Vidyard" id="CPw4UfSZxmTPkFvJSEC1x2" />

## Enabling WebAuthn With Device Biometrics

If you are currently using MFA with Auth0, biometrics can be enabled from the Auth0 dashboard. 

![Auth0 dashboard](https://images.ctfassets.net/23aumh6u8s0i/4UC4NaiiciIpjLGBPwab9h/07ea4d71950ba229bd3be05d8fb48696/unnamed-3.png)

After you enable it, users will receive prompts from enrolling their devices when authenticating; no code change is necessary.

Please refer to our documentation to learn more about [Auth0’s WebAuthn implementation](https://auth0.com/docs/mfa/fido-authentication-with-webauthn) in general and [WebAuthn for Device Biometrics](https://auth0.com/docs/mfa/configure-webauthn-device-biometrics-for-mfa) specifically.

## What’s Next

WebAuthn with Device Biometrics combines two authentication factors in one: something you have (the device) and something you are (the biometrics). In case you can’t use biometrics in the device, e.g., if you are wearing a mask, you’ll use something you have plus something you know (the passcode). As it’s stronger than a password and simpler to use, the next step is bringing it to passwordless authentication. Auth0 will support this in the same way we are doing it for MFA by letting users progressively enroll all of their devices. Stay tuned!

MFA With WebAuthn for FIDO Device Biometrics Now Available

Sam4-square

I'm an Identity nerd with many years of experience as a developer and advocate. I love explaining complex topics clearly and understandably. You can find me on stage at developer events worldwide or simply having great conversations in the hallway. Google has recognized me as a Google Developer Expert (GDE) in the domains of Web Technologies, Security, Privacy, Payments, and Identity.

Principal Developer Advocate

Sam Bellen

With resident credentials you can create a smoother, username-less login experience by saving some of the user data on the authenticator.


<div class="alert alert-info alert-icon">
  <i class="icon-budicon-500"></i>
  <strong>Want to learn more about WebAuthn? Then head over to <a href="https://webauthn.me/">webauthn.me</a> and don't forget to try the brand new debugger!</strong>
</div>

**TL;DR:** With the release of version 76, Google's Chrome browser [now supports WebAuthn resident keys](https://www.chromestatus.com/feature/4627499185078272). These allow for a smoother, username-less login experience by saving some of the user data on the authenticator. Let's have a look at how this works.

## WebAuthn Until Now

In a typical WebAuthn scenario, a credential ID is generated by the authenticator and saved on the server. This ID is used to identify the saved credential on the authenticator. We will save this credential ID linked to a username or other user identifiable property in our database.

When a user wants to authenticate using a previously created credential, they will enter their username in a login form. The server will look up the saved credential ID for this username and pass it along to the authenticator. The authenticator will then use this ID to select the correct credential to sign the authentication challenge.

This is a good solution, it eliminates the need for a password, and authenticates using the keys generated by the authenticator. The user still needs to enter a username every time they want to login. We can do better!

## Resident Credentials

When setting the `requireResidentKey` property to true, will force the browser to create a new client-side-resident public key credential source or resident credential for short, on the authenticator. With these resident credentials, the authenticator is able to select the appropriate credential private key based on the relying party ID.

For example, a user registers new credentials for the relying party with ID `auth0.com`. Any subsequent authentication request with that relying party will use the saved resident credential to find the corresponding credential private key unless an array of allowed credentials is configured in the `navigator.credentials.get()` options. 

To create a resident credential, you need an authenticator that is capable of creating one of these. Not all authenticators can do this. A Yubikey (4 or 5) and most other devices that support FIDO2 should be able to do this. There’s one caveat, your Yubikey should have a pin configured. If you don’t have an authenticator that supports resident credentials, it will throw an error.

## Step by Step

Let’s walk through this scenario step by step.

A user is new to your website and wants to configure a new credential using WebAuthn. You configured your relying party to set the `requiresResident` option to true, so the browser will try to create a resident credential.

Chrome will prompt the user which authenticator to use if it has found more than one.

![Choose an authenticator](https://images.ctfassets.net/23aumh6u8s0i/2xbPAhm7uuUnOoDctv9AZV/ddc965236705abf92d81d36cc602753f/choose-authenticator)

After selecting the authenticator of your choice, the browser will ask you to perform an action. In the case of my Yubikey 5C, it asks to touch the key. Note that it also mentions “A record of your visit to this site will be kept on your security key”. This “record” will be our resident key.

![Touch your security key](https://images.ctfassets.net/23aumh6u8s0i/2ntMji45OFRpMRd86vucC8/fde5589c360dd65b5fd6d152b30527ed/insert-authenticator)

If you don’t have a pin code configured on your authenticator, Chrome will ask you to do this at this point.

![Configure a pin code](https://images.ctfassets.net/23aumh6u8s0i/6EV7MFea4JlLilgVspP8ri/a3f5b33ac7ba4c8d65e30aada4cd9288/set-pin)

In case you already set up your authenticator with a pin code, you will have to enter the pin to continue.

![Enter your pin code](https://images.ctfassets.net/23aumh6u8s0i/38BniTjL2ASqlBEjwDDaSG/ff4258b36ae2300b830e62bce75c26c6/enter-pin)

To complete saving the resident credential, the browser will prompt a second time to confirm you want to create this credential.

![Confirm by touching your security key](https://images.ctfassets.net/23aumh6u8s0i/7BY9Q23ra2CXTEUmhqrKAW/888c98a897b180839b67ab4536a791bf/confirm-request)

We now have successfully registered a new client resident credential. When authenticating in the future, the browser will automatically use this credential, based on the relying party ID.

When there are more than one resident credentials saved on the authenticator, the browser will show a dialog where the user can select the credential they would like to use to authenticate.

![Choose which credential to use](https://images.ctfassets.net/23aumh6u8s0i/6IDvveTf1tv5n6TZjQL6o4/b02f58c082cb1d05a737cf3af3cb2099/choose-credential)

## Conclusion

After Microsoft's Edge browser already supported resident credentials, now also Chrome supports this feature. These kinds of credentials are saved on the authenticator, and allow the user to authenticate without even entering a username. The browser will recognize these credentials based on the relying party ID configured in the WebAuthn authentication request.

## Resources

[Introduction to Web Authentication](https://auth0.com/blog/introduction-to-web-authentication/)<br>
[webauthn.me](https://webauthn.me/)<br>
[WebAuthn Debugger](https://webauthn.me/debugger/)<br>




A Look at WebAuthn Resident Credentials

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

Embed Multi-Factor Authentication using push notifications, SMS, or TOTP anywhere, taking full control of the experience.



We are pleased to announce the availability of our [Multi-Factor Authentication API](https://auth0.com/docs/api-auth/tutorials/multifactor-resource-owner-password). Up to now, we have provided support for MFA through a simple switch in the Auth0 Dashboard, following our premise of *simplicity* and ease of use. However, we also believe in providing powerful *building blocks* for our users. For this reason we have developed a new API to perform the full MFA flow, even with multiple authenticators, in a flexible and convenient way. In this article we will take a look at the API and build a simple CLI app to demonstrate how to use it. Read on!

<include src="TweetQuote" quoteText="The MFA API is now available, learn how to embed MFA in your apps taking full control of the experience!"/>

> **Note**: for most MFA scenarios, we still recommend the use of [Universal Login](https://auth0.com/docs/hosted-pages/login) whenever possible. This new API is meant for advanced use cases where Universal Login is not flexible enough. [Universal Login is the best alternative](https://auth0.com/blog/authentication-provider-best-practices-centralized-login/) in most cases.

---

## Why?
Up to now, enabling MFA at Auth0 was simply a matter of flipping a switch and optionally selecting which application you wanted to enable MFA for. When MFA is enabled, hitting the `/authorize` endpoint or starting an authorization flow through one of our libraries was enough to trigger MFA. Simple, convenient.

![MFA Switch](https://images.ctfassets.net/23aumh6u8s0i/4Fk1xnLP6wm5Ay24YJLeex/c7047fc95a6712dfa7a92f5b7c5522e7/1-mfa-enable)

However, some of our customers have requested to have more control over the MFA process. For this reason, we have been working with [ATEA Norge](https://www.atea.no/) and other customers under a private BETA program to find the right implementation for this feature. The result: a new API for MFA to give back control to you when required. Let's check it out.

> **Note**: for most MFA scenarios, we still recommend the use of [Universal Login](https://auth0.com/docs/hosted-pages/login) whenever possible. This new API is meant for advanced use cases where Universal Login is not flexible enough. [Universal Login is the best alternative](https://auth0.com/blog/authentication-provider-best-practices-centralized-login/) in most cases.

## A Simple API
The API works by introducing some changes to how the `/token` endpoint behaves. Let's take a look.

<include src="TweetQuote" quoteText="The new MFA API is simple, it works on top of the existing /token endpoint."/>

The API works in four simple steps:

1. Access token request to `/token`.
2. Challenge request to `/challenge`.
3. Asking the user for a code (if necessary).
4. Final request to `/token`.

> This scenario assumes the user is already enrolled in MFA and has at least one authenticator enabled. There's also a [new API for enrollment](https://auth0.com/docs/multifactor-authentication/api/otp) to have full control over the enrollment process. This API also allows for obtaining a list of associated authenticators, useful for using multiple authenticator, as we will see in step 2 below.

### 1. Access Token Request to `/token`
When a request is made to the `/token` endpoint to get an access token, normally you either get an error, or you get an access token. However, when the MFA API is enabled, the `/token` endpoint may return a new error code: `mfa_required`.

```
POST /oauth/token HTTP/1.1
...

{
  "username": "...",
  "password": "...",
  "grant_type": "password"
  ...
}
```

Response:

```
HTTP/1.1 403 Forbidden
...

{
  "error": "mfa_required",
  "mfa_token": "..."
}
```

The `mfa_token` in the response value must be used in the following requests.

> MFA is also supported for the `refresh_token` [grant type](https://auth0.com/docs/applications/application-grant-types). This allows for use cases in which you want to require 2FA (TOTP, SMS, push notifications) when refreshing an access token, useful for extra security and step-up authentication.

### 2. Perform an MFA Challenge
When the `mfa_required` error is returned, the client must then perform a `challenge`. This is done by sending a request to the `/mfa/challenge` endpoint.

```
POST /mfa/challenge HTTP/1.1
...

{
  "mfa_token": "<from step 1>",
  "challenge_type": "otp oob",
  "authenticator_id": "optional, if known"
}
```

Response:

```
HTTP/1.1 200 OK
...

{
  "challenge_type": "oob",
  "binding_method": "prompt",
  "oob_code": "..."
}
```

The response tells the client which type of authenticator will be used (`challenge_type`) and also returns additional arguments relevant for that method. The `binding_method` parameter tells the client it should ask the user for a code.

The client may optionally request a specific authenticator through `authenticator_id`. This allows for multiple authenticators, even for the same resource.

> `OOB` means "out-of-band". All methods that are not [TOTP](https://auth0.com/blog/from-theory-to-practice-adding-two-factor-to-node-dot-js/) are OOB.

### 3. Prompt For Input (If Necessary)
If the `challenge_type` is `otp` or the `binding_method` parameter is set to `prompt`, the client should ask the user to input a code before continuing.

### 4. Get The Access Token
Finally, a new request to the `/token` endpoint is performed.

```
POST /oauth/token HTTP/1.1
...

{
  "mfa_token": "<from step 1>",
  "oob_code": "<from step 2, optional>",
  "binding_code": "<from step 3, if 'binding_method' === 'prompt'>",
  "otp": "<from step 3, if challenge_type === 'otp'>",
  "grant_type": "<one of two strings, see below>"
}
```

Grant type must be one of two values:
- For OTP: `http://auth0.com/oauth/grant-type/mfa-otp`
- For OOB: `http://auth0.com/oauth/grant-type/mfa-oob`

Response:

```
HTTP/1.1 200 OK
...

{
  "access_token": "...",
  "expires_in": "...",
  ...
}
```

Note that certain methods do not require the user to input anything (push notifications, for example). For those cases, this request must be performed repeatedly until an access token is returned or the authorization is denied. If the client is expected to repeat the request again in the future (after a certain amount of time) the response will be:

```
HTTP/1.1 400 Bad Request
...

{
  "error": "authorization_pending"
}
```

This means the user has not performed any actions yet and the client should wait a bit before trying again. The `error` can also be `slow_down` if the client is not waiting enough between requests.

That's it! If all went well, you now have an access token issued through MFA!

## Example: A CLI App with MFA
To give you a better understanding of how the API works we have developed a [simple CLI app that uses MFA](https://github.com/auth0-blog/oauth2-mfa-cli-example).

<video src="https://cdn.auth0.com/blog/oauth2-mfa-api/cli-demo-2.m4v" controls autoplay loop></video>

Take a look at the [full code in GitHub](https://github.com/auth0-blog/oauth2-mfa-cli-example). You will find the interesting bits in the `/token-endpoint.mjs` file, particularly in the `token` function.

To use the app, make sure that:
- You have created a new [Application](https://manage.auth0.com/#/applications) in the Auth0 Dashboard. Select the `Machine-to-Machine type`.
- The `token authentication method` is set to `none` in the Auth0 Application settings.
- You have enabled the `Password` and `MFA` grants in `Application -> Advanced Settings -> Grant Types`.
- You have MFA enabled. Go to [Multifactor Auth](https://manage.auth0.com/#/guardian) and enable SMS and push notifications for [Guardian](https://auth0.com/docs/multifactor-authentication/guardian/user-guide).
- You have set the right client ID (get this from the [application](https://manage.auth0.com/#/applications) settings area) in the MFA rule in the [Multifactor Auth](https://manage.auth0.com/#/guardian) section. Otherwise MFA will be enabled for all clients.

To use the app simply do:

```sh
git clone git@github.com:auth0-blog/oauth2-mfa-cli-example.git
cd oauth2-mfa-cli-example
npm install
node src/index.js login
```

The app supports some other commands. You can take a look at them by running it with no arguments.

## Other Use Cases
The sky is the limit! Here are some scenarios where using the new MFA API could make sense:

- Protect a VPN like OpenVPN (Pritnul) or Juniper with a second factor.
- Integrate with a PAM module to do second factor with SSH.
- Integrate with an LDAP service to provide a second factor.
- Step up authentication when refreshing an `access_token` (`refresh_token` grant).
- Trigger second factor from any backend process.

You are now free to build powerful MFA flows wherever you want!

## Conclusion
The MFA API brings flexibility to the use of MFA in your apps. One thing you may have noticed is that we are using the [OAuth 2.0 `/token` endpoint](https://tools.ietf.org/html/rfc6749#section-3.2). In fact, we designed this to be compatible with OAuth 2.0 right from the start. We have prepared two specification drafts, [one for MFA](https://github.com/jaredhanson/draft-oauth-mfa/blob/master/Draft-1.0.txt), [the other for authenticator association](https://github.com/jaredhanson/draft-oauth-mfa-assoc/blob/master/Draft-1.0.txt), to be sent to the [IETF OAuth 2.0 Working Group](https://tools.ietf.org/wg/oauth/). Other implementations of OAuth 2.0 can follow these specifications to implement MFA in a flexible, yet powerful way, while remaining compatible. We will have more information about this in an upcoming post.

We can't wait to see how you use this API to build powerful multi-factor flows! Let us know what you think in the comments.

<include src="TweetQuote" quoteText="We can't wait to see how you use this API to build powerful multi-factor flows!"/>


Introducing the Multi-Factor Authentication API

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

Learn about the Guardian Whitelabel SDK and how you can easily build your own authenticator leveraging our battle-tested solution.



On November 23, 2016, we tagged the first release of [Guardian for iOS](https://github.com/auth0/Guardian.swift) and [Android](https://github.com/auth0/Guardian.Android), a whitelabel SDK to help users, developers, and organizations build their own authenticator and Guardian-like applications. Read on to find out how it works and how you can use it in your projects!

<include src="TweetQuote" quoteText="The Guardian Whitelabel SDK helps you build your own authenticator and Guardian-like applications."/>


## White-label Multifactor

You can use the Guardian Mobile SDKs - available for [iOS](https://auth0.com/docs/multifactor-authentication/developer/libraries/ios) and [Android](https://auth0.com/docs/multifactor-authentication/developer/libraries/android) to build your own white-label multifactor authentication application with complete control over the branding and look-and-feel.

![White label Multifactor](https://images.ctfassets.net/23aumh6u8s0i/2wDZpATaJGhuzlegN5qFCl/1c4ed85770b4f91583e9999cb896595c/sdk)

## Guardian

[Guardian](https://auth0.com/docs/multifactor-authentication/guardian) is Auth0's multifactor authentication solution that provides a simple and secure way to implement Multifactor Authentication. It also supports [push notifications](https://auth0.com/docs/multifactor-authentication/administrator/push-notifications), removing the need for one time pass codes for a truly frictionless multifactor experience. 

<video autoplay loop width="600">
    <source src="https://cdn.auth0.com/blog/guardian/guardian-2.m4v"/>
</video>

The Guardian app can be downloaded from the [App Store](https://itunes.apple.com/us/app/auth0-guardian/id1093447833) or from [Google Play](https://play.google.com/store/apps/details?id=com.auth0.guardian).

With the Guardian SDK([iOS](https://github.com/auth0/Guardian.swift) and [Android](https://github.com/auth0/Guardian.Android)), you can build your own custom mobile applications that works like *Guardian* or integrate some Guardian functionalities, such as receiving *Push Notifications* in your existing mobile applications. 

A typical scenario could be: While building a banking app, you can make use of the Guardian SDK in your existing mobile app to receive and confirm push notifications when someone performs an ATM  transaction.

## How can I use it? 

Take a look at the [iOs](https://auth0.com/docs/multifactor-authentication/developer/libraries/ios) and [Android](https://auth0.com/docs/multifactor-authentication/developer/libraries/android) docs. You can also just enable push notifications and SMS by toggling the buttons below from the Auth0 [dashboard](https://management.auth0.com).

![Enable Push Notifications and SMS](https://images.ctfassets.net/23aumh6u8s0i/5QngrxnuyVTdOSLgON7kh6/d8b489ae32ed8de0f7d4880e20e41a8f/enable)
_Push Notifications and SMS_

## Conclusion

The Guardian Mobile SDK opens up a myriad of opportunities for developers and organizations wishing to leverage an already secure, tested and existing solution for building and enhancing their mobile apps. Try it today!


"authenticator"