william_johnson

  Will Johnson is a Developer Advocate at Auth0. He loves teaching topics in a digestible way to empower more developers. He writes blog posts, records screencasts, and writes eBooks to help developers. He's also an instructor on <a target='_blank' rel='noopener noreferrer' href='https://egghead.io'><strong><b>egghead.io</b></strong></a>.


Developer Advocate

Will Johnson

Learn why native Google Sign-In creates a faster, more trusted login for your Android app. See how Auth0 and Credential Manager deliver a seamless UX.

When you're building a mobile app, login flow is one of the first places users decide if your app feels polished or clunky. For Android users, nothing feels more natural than using the Google account already on their phone to log in. That’s what native Google Sign-In offers: no redirects, no browser tabs, just a fast, familiar experience.
Auth0 supports this native flow, allowing you to authenticate users with their Google account and still benefit from all of Auth0’s token handling, identity verification, and security features. The end result is a login experience users trust, while keeping your backend logic and architecture unchanged.

## Why native Google Sign-In is worth it

If you’re using [Auth0 Universal Login](https://auth0.com/docs/authenticate/login/auth0-universal-login) already, you might be wondering if native Google Sign-In is worth the extra effort. Spoiler alert: **It is!** Here are some reason why developers who care about speed, UX, and brand trust should consider going native on Android.

### Faster login times

Native sign-in eliminates the browser round-trip, a process that can take several seconds due to network latency, page loads, and redirects. By using the on-device account directly, the login time is reduced to the milliseconds it takes for the native UI to appear, often resulting in a 70-80% faster login experience.

### Future-proofing with Android Credential Manager

Beyond the immediate UX gains, choosing the native flow is a strategic decision that aligns your app with the future of the Android platform. Google not only recommends this approach but has built its modern identity tools around it.

This flow is designed to work directly with [Credential Manager](https://developers.google.com/identity/android-credential-manager), which is Android's unified home for all sign-in methods, including passwords, passkeys, and federated logins like Google. By adopting this modern API, your app can securely retrieve saved credentials from the Google Password Manager, enabling the same seamless, one-tap sign-in for returning users that was previously offered by Smart Lock.

For developers, this means you're building on a future-proof foundation. As Google evolves its identity and authentication features, your app will be positioned to seamlessly integrate them, reducing long-term maintenance and keeping your app feeling modern and integrated into the Android ecosystem.

### A seamless UX that builds trust

Redirecting users to a browser breaks the trusted context of your application. That brief journey to an external web view introduces uncertainty: "Is this the real Google login page, or a phishing attempt?" Native sign-in reinforces the principle of a secure boundary. The login prompt is presented by the Android OS itself, a universally trusted party, that assures the user that their credentials are being handled securely within the device's native ecosystem.

> Why trust matters: For apps that handle sensitive data, such as finance or healthcare, building trust at every step is essential. Redirecting users to an external web view can break that trust by introducing unfamiliar UI or delays. In an Auth0 UX research study, a developer from the financial sector shared that they couldn’t afford any hiccups in the user flow. Because their app required users to enter sensitive financial data, building complete trust was a priority, and web redirects didn’t provide the same level of reassurance as a native experience.

Native sign-in reinforces credibility by keeping the flow consistent, fast, and secure, just what high-trust industries demand.

And best of all, Auth0 lets you implement this while keeping your existing identity setup.

## Under the hood: How native login works

So, how does this flow achieve both a seamless user experience and security? It relies on a multi-step handshake between your app, the Android OS, and Auth0.

Consider the following diagram:

![](https://images.ctfassets.net/23aumh6u8s0i/2fTJqdIeKLQ433qRHT4lua/8f416489dc0b87eaa9dd97c821aba70b/Untitled_diagram___Mermaid_Chart-2025-07-16-193722.png)

Following the numbered arrows, here is a breakdown of the flow in the diagram:

1. **Request Credential:** Your Android app initiates the login by asking the Android OS's
Credential Manager for a Google credential, providing a unique nonce for security.

2. **User Interaction:** The Credential Manager displays the familiar, native Google account picker to the user. 

3. **Account Selection:** The user selects their account.

4. **Google Issues Token:** The Credential Manager communicates with Google's services in the background, which issue a secure, signed ID Token.

5. **Token Received by Credential Manager:** The Credential Manager receives the ID Token issued by Google.

6. **Token Received by App:** The ID Token is passed back to your Android app.

7. **Token Exchange with Auth0:** Your app sends this Google ID Token to Auth0 along with the nonce generated at the request time.

8. **Validation:** Auth0 validates the token's signature using Google's public keys and verifies the nonce to prevent replay attacks.

9. **Auth0 Credentials Issued:** Upon successful validation, Auth0 returns its own set of credentials (an Access Token and ID Token) to your app.

10. **Login Complete!** Your app now has a secure session managed by Auth0.

Two security concepts make this handshake work:

* **The ID Token as Proof:** When a user consents, the Android OS doesn't just return a username. It asks Google to generate a signed ID Token (a JSON Web Token, or JWT). This token is a verifiable piece of cryptographic proof that contains the user's identity, who it was issued to (your app), and most importantly, a nonce.

* **The nonce and the Secure Exchange:** The nonce (number used once) is a random, unique string your app generates at the start of each login attempt. It gets embedded inside the signed ID Token from Google. When your app sends this token to Auth0, Auth0 performs a critical check: it verifies that the nonce inside the token matches the one it expected for that specific transaction. This instantly defeats replay attacks, where an attacker might try to reuse an old or stolen token. Once validated, Auth0 exchanges the Google ID Token for a set of its own credentials.

## How the concepts look in code

Now that you understand the "why," let's walk through how the pieces connect in practice. The following code snippets, also available in a [GitHub Gist](https://gist.github.com/willjohnsonio/e2ecd4cec1fbcebc933f796fe010a347), illustrate the core steps of the flow in an Android app.

**Step 1: Requesting credentials from Google**

First, use `GetGoogleIdOption` to configure your request. This is where you’ll provide two crucial pieces of security information:

* `setServerClientId(...)`: This must be the Client ID from your Web Application credentials in the Google Cloud Console. This tells Google that you intend for the resulting ID Token to be used by a backend server (in this case, Auth0).

* `setNonce(...)`: Provide a unique, random string for every login

```kotlin
val randomNonce = UUID.randomUUID().toString()

val googleIdOption = GetGoogleIdOption.Builder()
    .setFilterByAuthorizedAccounts(false)
    .setServerClientId(getString(R.string.com_google_client_id))
    .setNonce(randomNonce)
    .build()

val request = GetCredentialRequest.Builder()
    .addCredentialOption(googleIdOption)
    .build()
```

**Step 2: Handling a unified result**

A key concept to understand is that Credential Manager is a unified API. It’s built to handle not just "Sign in with Google," but also saved passwords and modern passkeys, all through the same entry point. Because of this, your code must check what type of credential the user actually selected.

The standard way to do this is with a `when` statement. You inspect the `result` from the `getCredential()` call to confirm it's the specific type you're expecting for this flow: `TYPE_GOOGLE_ID_TOKEN_CREDENTIAL`. This check ensures your app responds correctly and securely.

Once you've verified the type, you can then "unbox" the data to get the Google ID Token.

```kotlin
try {
    val credMan = CredentialManager.create(this)
    val result = credMan.getCredential(
        context = this,
        request = request
    )

    val creds = result.credential
    when (creds) {
        is CustomCredential -> {
            if (creds.type == GoogleIdTokenCredential.TYPE_GOOGLE_ID_TOKEN_CREDENTIAL) {
                val googleCredentials = GoogleIdTokenCredential.createFrom(creds.data)
                // Rest of the code
            }
        }
        // Handle other credential types like passkeys or passwords if needed
        else -> {
            // Handle other cases or errors
        }
    }
} catch (e: GetCredentialException) {
    // Handle exceptions from getCredential(), such as the user canceling the flow
}
```

**Step 3: Exchanging the token with Auth0**

Finally, you send the `idToken` from Google to Auth0 using the `loginWithNativeSocialToken` method. The `tokenType` parameter is important, because it tells Auth0 which validation strategy to use. In this case, it will use Google's public keys to verify the token's signature.

```kotlin
auth0Client.loginWithNativeSocialToken(
    googleCredential.idToken,
    "http://auth0.com/oauth/token-type/google-id-token"
)
.setScope("openid profile email")
.start(object : Callback<Credentials, AuthenticationException> {
    override fun onSuccess(auth0Creds: Credentials) {
        // Store credentials and update UI
    }

    override fun onFailure(error: AuthenticationException) {
        // Show error message
    }
})
```

## Upgrade your Android users sign-in experience with Auth0

If your Android app already uses Auth0, native Google Sign-In is one of the easiest upgrades you can make for a better user experience. It’s fast, secure, and better aligned with Android platform expectations.

Native Google Sign-In gives you a more trusted, smoother login experience that fits naturally into the Android ecosystem, all without requiring backend changes or major migrations.

To learn more, check out the Auth0 docs on [Native Google Sign-In](https://auth0.com/docs/authenticate/identity-providers/social-identity-providers/google-native).

Why Native Google Sign-In Makes Android Apps Feel Right

carla_urrea

I've been working as a software engineer since 2014, particularly as a backend engineer and doing system design. I consider myself a language-agnostic developer but if I had to choose, I like to work with Ruby and Python.  

After realizing how fun it was to create content and share experiences with the developer community I made the switch to Developer Advocacy. I like to learn and work with new technologies. 

When I'm not coding or creating content you could probably find me going on a bike ride, hiking, or just hanging out with my dog, Dasha. 

Staff Developer Advocate

Carla Urrea Stabile

Native login with passkeys is now available, so let’s take a look at how to sign up and log in on Android using Auth0’s Native Login.

How to Sign Up and Log In with Passkeys in Android Using Auth0's Native Login

Native login with passkeys allows you to integrate passkeys into your native applications and offers a smooth user experience with all the benefits of passkeys.

Native login with passkeys allows you to seamlessly integrate [passkeys](https://learnpasskeys.io/introduction) into your mobile applications. If you wanted to add passkeys before, you had to integrate a web redirect flow that uses Universal Login. 

Today, we are announcing Limited Early Access to Native Login with passkeys for Android applications. 

## How Does It Work? 

In order to use Native Login with passkeys in your Android application, there are a few requirements:

* **Enable and configure your passkey policy**: First of all, you need to enable passkeys for your tenant. Learn how to do it using [our documentation](https://auth0.com/docs/authenticate/database-connections/passkeys/configure-passkey-policy).
* **Configure a Custom Domain**: you can learn how to configure a custom domain using [our documentation](https://auth0.com/docs/customize/custom-domains).
* **Enable Android App Links Support**, which you can do following [our docs](https://auth0.com/docs/get-started/applications/enable-android-app-links-support).

Native login is available on the Android SDK from version 3.2.0 and Android API 28. 

### Sign Up 

To sign up, you’ll need to use the "`signupWithPasskey`" method from the "`AuthenticationAPIClient`". When successful, you can handle the passkey creation from your device using Android’s CredentialManager following [Android’s official docs](https://developer.android.com/identity/sign-in/credential-manager#create-passkey). Here’s an example implementation in Kotlin:

```java
val account = Auth0.getInstance("{YOUR_CLIENT_ID}", "{YOUR_DOMAIN}")

val client = AuthenticationAPIClient(account) 

client.signupWithPasskey(
            UserData(
                email = "jndoe@email.com"
            ), "{realm}"  
        ).start(object : Callback<PasskeyRegistrationChallenge, AuthenticationException> {
            override fun onSuccess(result: PasskeyRegistrationChallenge) {
                val passKeyRegistrationChallenge = result
                val request = CreatePublicKeyCredentialRequest(
                    Gson().toJson(
                        passKeyRegistrationChallenge.authParamsPublicKey
                    )
                )
                var response: CreatePublicKeyCredentialResponse?

        // start credential creation on the device 
                credentialManager.createCredentialAsync(requireContext(),
                    request,
                    CancellationSignal(),
                    Executors.newSingleThreadExecutor(),
                    object :
                        CredentialManagerCallback<CreateCredentialResponse, CreateCredentialException> {

                        override fun onError(e: CreateCredentialException) {
                        }

                        override fun onResult(result: CreateCredentialResponse) {

                            response = result as CreatePublicKeyCredentialResponse
                            val authRequest = Gson().fromJson(
                                response?.registrationResponseJson,
                                PublicKeyCredentials::class.java
                            )

       // once the device created the key pair and signed the challenge you can sign in to Auth0 
                            client.signinWithPasskey(
                                passKeyRegistrationChallenge.authSession,
                                authRequest,
                                "{realm}"
                            )
                                .validateClaims()
                                .start(object : Callback<Credentials, AuthenticationException> {
                                    override fun onSuccess(result: Credentials) {
                                        credentialsManager.saveCredentials(result)
                                        Snackbar.make(
                                            requireView(),
                                            "Hello ${result.user.name}",
                                            Snackbar.LENGTH_LONG
                                        ).show()
                                    }

                                    override fun onFailure(error: AuthenticationException) {
                                        Snackbar.make(
                                            requireView(),
                                            error.getDescription(),
                                            Snackbar.LENGTH_LONG
                                        ).show()
                                    }
                                })
                        }
                    })
            }

            override fun onFailure(error: AuthenticationException) {
                Snackbar.make(
                    requireView(),
                    error.getDescription(),
                    Snackbar.LENGTH_LONG
                ).show()
            }
        })
```

The `signupWithPasskey` method starts the passkey creation ceremony. It generates the challenge for the authenticator to sign once it has created the public key credential pair. In your case, your Android device acts as the authenticator and you create the key pair and sign the challenge when you use the `CreatePublicKeyCredentialRequest` method from Android’s Credential Manager. 

Then, you can use Android’s Credential Manager method `createCredential` or `createCredentialAsync` to start the creation. Once successful, you can use the result from the creation to send that data to Auth0 and sign in using the ``signinWithPasskey`` method, which is covered below.

### Login 

To sign in, you’ll have to first initiate the passkey challenge by using the `passkeyChallenge` method from the `AuthenticationAPIClient`. When the call is successful, you can initiate the credential retrieval using Android’s [`getCredential` method from the `CredentialManager`](https://developer.android.com/identity/sign-in/credential-manager#sign-in).

When your device retrieves the credential successfully, you can then initiate the sign-in process with Auth0. An example implementation could be:

```java
val account = Auth0.getInstance("{YOUR_CLIENT_ID}", "{YOUR_DOMAIN}")
val client = AuthenticationAPIClient(account)

client.passkeyChallenge(realm)
            .start(object : Callback<PasskeyChallenge, AuthenticationException> {
                override fun onSuccess(result: PasskeyChallenge) {
                    val passkeyChallengeResponse = result
                    val request =
                        GetPublicKeyCredentialOption(Gson().toJson(passkeyChallengeResponse.authParamsPublicKey))
                    val getCredRequest = GetCredentialRequest(
                        listOf(request)
                    )
                    credentialManager.getCredentialAsync(context,
                        getCredRequest,
                        CancellationSignal(),
                        executor,
                        object :
                            CredentialManagerCallback<GetCredentialResponse, GetCredentialException> {
                            override fun onError(e: GetCredentialException) {
                                Log.w(TAG, "Error fetching public key credential")
                                callback.onFailure(handleGetCredentialFailure(e))
                            }

                            override fun onResult(result: GetCredentialResponse) {
                                when (val credential = result.credential) {
                                    is PublicKeyCredential -> {
                                        val authRequest = Gson().fromJson(
                                            credential.authenticationResponseJson,
                                            PublicKeyCredentials::class.java
                                        )
                // initiate signin process with Auth0
                                        client.signinWithPasskey(
                                            passkeyChallengeResponse.authSession,
                                            authRequest,
                                            realm
                                        )
                                            .validateClaims()
                                            .addParameters(parameters)
                                            .start(callback)
                                    }

                                    else -> {
                                        Log.w(
                                            TAG,
                                            "Received unrecognized credential type ${credential.type}."
                                        )
                                        callback.onFailure(AuthenticationException("Received unrecognized credential type ${credential.type}"))
                                    }
                                }
                            }
                        })

                }
```

For more detailed examples, you can check out the [Android SDK sample folder on Github](https://github.com/auth0/Auth0.Android/tree/main/sample).

If you need [Java examples, you can check out this doc](https://github.com/auth0/Auth0.Android/blob/main/EXAMPLES.md#passkeys).

## What Use Cases Are Supported?

The initial early access release provides support for the following use cases:

* **Sign Up with a passkey**: users can register a new passkey for Auth0/your app and store it in the device credential manager for future use. 
* **Login with a passkey**: users can retrieve passkeys using the device’s credential manager and use them to log in. 

## How Can You Apply?

If you are interested in joining the early access program, please reach out to your account manager.

_Any products, features, or functionality referenced in this material that are not currently generally available may not be delivered on time or at all. Product roadmaps do not represent a commitment, obligation, or promise to deliver any product, feature, or functionality, and you should not rely on them to make your purchase decisions._

Native Login with Passkeys Is Now in Limited Early Access for Android Applications!

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

Deploy a cloud-native Java Spring Boot microservice stack secured with Auth0 on Google GKE using Terraform and Kubernetes.

Deploy Secure Spring Boot Microservices on Google GKE Using Terraform and Kubernetes

Deploy a cloud-native Java Spring Boot microservice stack secured with Auth0 on Azure AKS using Terraform and Kubernetes.

Deploy Secure Spring Boot Microservices on Azure AKS Using Terraform and Kubernetes

peterfernandez_360

As an Architect, Consultant, and Engineer, I have more than 30 years of experience designing and developing secure and robust software solutions. When not helping teams deal with the complexities of Customer Identity, you can usually find me working behind the scenes, acting in or directing a show at my local theatre.

Principal Developer Advocate

Peter Fernandez

A step-by-step guide to leveraging OAuth 2.0 when accessing protected APIs via an iOS app built with Swift and integrated with Auth0.

Calling a Protected API from an iOS Swift App

joey devilla headshot 900px

I’m a Senior Developer Advocate at Auth0, and I like to work on various technologies. I’ve developed software for all sorts of platforms, from CD-ROM and the PalmPilot to my current area of focus, mobile phones, IoT devices, and AI. When I’m not looking for strange new platforms to write software for, I’m playing a strange old instrument — the accordion!

Senior Developer Advocate

Joey deVilla

Add personalization to your iOS/SwiftUI app with user info from the ID token, a JWT (JSON Web Token) that you’ll read with the Swift JWTDecode library.

In Part 1 of this tutorial, you created a SwiftUI-based iOS app that uses Auth0 for basic login and logout functionality. In this part, you’ll enhance your app by giving it the ability to read the user’s profile to display their photo, name, and email address when they’re logged in.

<include 
    src="LinkCard" 
    title="Calling a Protected API from an iOS Swift App" 
    link="https://auth0.com/blog/calling-protected-apis-from-ios-swift/" 
    description="Looking for a step-by-step guide to leveraging OAuth 2.0 when accessing protected APIs via an iOS app built with Swift? If you're integrating with Auth0, then this is everything you need to know!"     img="https://images.ctfassets.net/23aumh6u8s0i/5PC3nu1F68m8S3BmJFv9SN/e83487c6d89d72fb6a49155722959b1d/ios_hero_2021_2.jpeg"
/>

Once again, you can follow the text in this article, or if you prefer learning by video, you can follow the steps in this article’s companion video:

<iframe width="600" height="338" src="https://www.youtube.com/embed/xOBoLegDmTw" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

> Look for the 🛠 emoji if you’d like to skim through the content while focusing on the build and execution steps.
> 
> The 📺 emoji highlights links to specific points in the video.


## Examine the ID Token

📺 [The _Examine the ID Token_ section of the video](https://www.youtube.com/watch?v=xOBoLegDmTw&t=2008s)
 
If you look at the `.success` case of the `switch` statement in `ContentView`’s `login()` method, you’ll see these `print()` functions:

```swift
print("Credentials: \(credentials)")
print("ID token: \(credentials.idToken)")
```

These functions’ output will appear in Xcode’s Debug area:

![Xcode screenshot highlighting the Debug area.](https://images.ctfassets.net/23aumh6u8s0i/2Odv2P2CeeMGBoKSHNl3ly/2ba5ae37dbc5afafb94e82f95f41a722/debug_area.png)

> If the Debug area isn’t visible, open the _View_ menu and select _Debug Area_ → _Show Debug Area_ or use the keyboard shortcut _command-Shift-Y_.

You’ll see the contents of the `credentials` object and its `idToken` property, which should look similar to this:

```
Credentials: Credentials(accessToken: "<REDACTED>", tokenType: "Bearer", idToken: "<REDACTED>", refreshToken: nil, expiresIn: 2022-03-20 04:38:25 +0000, scope: Optional("openid profile email"), recoveryCode: nil)
ID token: eyJhbGciOiJSUzI1NiIsInR5cC...
```

The `credentials` object is a package of information that Auth0 sends to your app after authenticating a user. This information includes:

- **ID token:** Data that proves that the user has been authenticated.
- **Access token:** Data that gives a client application permission to access a specific resource to perform specific actions on the user’s behalf.
- **Refresh token:** Applications use this to get additional access tokens when the original access token expires without requiring the user to re-authenticate.
- **Scopes:** A set of [OpenID Connect (OIDC) scopes](https://auth0.com/docs/get-started/apis/scopes/openid-connect-scopes) — authorizations for access to details about the user — that Auth0 has granted to the app. Unless you specify otherwise, *Auth0.swift* defaults to requesting the following scopes when logging in a user:
	- `openid`: Authorization to use OIDC to verify the user's identity
	- `profile`: Authorization to access the user’s name information
	- `email`:  Authorization to access the user’s email address

> Want to know more about ID tokens and access tokens? We explain all in our article, [_ID Token and Access Token: What's the Difference?_](https://auth0.com/blog/id-token-access-token-what-is-the-difference/)
> 
> Want to know more about refresh tokens? See our article, [_What Are Refresh Tokens and How to Use Them Securely_](https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/).

The piece of information that we’re most interested in (for this exercise) is the ID token.

When the `print()` function is used to output the contents of `credentials`, the values of the `idToken` and `accessToken` properties are replaced with the string `<REDACTED>` as a security measure. Malicious parties can use tools to capture the output of `print()` functions from production apps; this is why `Credentials` instances redact the values of their `idToken` and `accessToken` properties when printed.

Note that when we use the `print()` function to output `credentials.idToken` — the ID token itself — the value is _not_ redacted. That’s because this value is useful for debugging, which we’ll do in the next step.

> It’s fine to print the value of the ID token to the debug console while you’re learning about the authentication process or building the app. Make sure you remove `print()` statements — especially those that print sensitive information, such as the ID token — before putting them into production!


### What’s in the ID token?

📺 [The _What’s in the ID token?_ section of the video](https://www.youtube.com/watch?v=xOBoLegDmTw&t=2118s)

To see what’s in the ID token, copy its value from the Debug area, go to Auth0’s [JWT.io site](https://jwt.io/) and paste that value into the _Encoded_ text area on the left side of the page. JWT.io will decode the ID token from its JWT form and display its decoded contents in the _Decoded_ area on the page’s right side:

![JWT.io and the decoded ID token.](https://images.ctfassets.net/23aumh6u8s0i/4sg6VirydfCzVVenH6LWil/174552abed55b4fe3d8100493c1510db/jwt.io_screenshot.png)

In the _Decoded_ area’s _Payload_ section, you’ll see the decoded user information from the ID token, including the data that we want the app to display: the user’s name, email address, and picture.

In the next step, we’ll give the app the same ID token-decoding capability as JWT.io’s.

> Auth0 has plenty of information about JWTs. In addition to the main [JWT.io page](https://jwt.io/), you should visit JWT.io’s [_Introduction to JSON Web Tokens_](https://jwt.io/introduction) and download our [free JWT Handbook](https://auth0.com/resources/ebooks/jwt-handbook).


## Get the User’s Information

📺 [The _Get the User’s Information_ section of the video](https://www.youtube.com/watch?v=xOBoLegDmTw&t=2223s)

The app only “knows” whether the user is logged in or logged out in its current state. It also has information about the user’s identity encoded in the ID token. Let’s extract this user information — the *user profile* — and use it to display the user’s name, email address, and picture when the user is logged in. 

🛠 In `Profile`, add the following `import` statement before the `struct Profile` line:

```Swift
// [ 📄 Profile.swift ]

import JWTDecode

// [ More code here ]
```

🛠 In the `Profile` extension, replace the `// TODO: Implement the 'from()' method.` comment with this `from()` method. It uses a couple of methods from the newly-imported `JWTDecode` library:

```swift
// [ 📄 Profile.swift ]

// [ More code here ]

  static func from(_ idToken: String) -> Self {
    guard
      let jwt = try? decode(jwt: idToken),
      let id = jwt.subject,
      let name = jwt.claim(name: "name").string,
      let email = jwt.claim(name: "email").string,
      let emailVerified = jwt.claim(name: "email_verified").boolean,
      let picture = jwt.claim(name: "picture").string,
      let updatedAt = jwt.claim(name: "updated_at").string
    else {
      return .empty
    }

    return Profile(
      id: id,
      name: name,
      email: email,
      emailVerified: String(describing: emailVerified),
      picture: picture,
      updatedAt: updatedAt
    )
  }
  
// [ More code here ]
```

Given an ID token string, the `from()` function creates a `Profile` instance. If `from()` can extract claims — values about the user’s identity, which include their name, email address, and the URL for their picture — from the ID token, it returns a `Profile` instance with that information in its properties. Otherwise, it returns a `Profile` instance with empty properties.


## Display the User’s Information

📺 [The _Display the User’s Information_ section of the video](https://www.youtube.com/watch?v=xOBoLegDmTw&t=2424s)

Now that there’s a way to extract information from an ID token, let’s put it to use. 

Since `userProfile` is marked with the `@State` attribute, it defines the user interface’s state. Whenever `userProfile` or one of its properties changes, the app redraws the user interface to reflect the change.

We want to display the user’s information when they log in, so we’ll use `Profile`’s newly-created `from()` method in the `login()` method.

🛠 Open `ContentView` and update `login()` as shown below:

```swift
// [ 📄 ContentView.swift ]

// [ More code here ]

  func login() {
    Auth0 // 1
      .webAuth() // 2
      .start { result in // 3
        switch result {
          // 4
          case .failure(let error):
            print("Failed with: \(error)")
          // 5
          case .success(let credentials):
            self.isAuthenticated = true
            // 👇🏽👇🏽👇🏽 New line of code here!
            self.userProfile = Profile.from(credentials.idToken)
            // 👆🏽👆🏽👆🏽
            print("Credentials: \(credentials)")
            print("ID token: \(credentials.idToken)")
        }
      }
  }

// [ More code here ]
```

The newly-added line of code runs after the user logs in, and the app receives the ID token. It creates a new `Profile` instance from the data in the ID token and sets `ContentView`’s `userProfile` property to that instance.

When the user logs out, we should clean up the user profile just to be safe.

🛠 Update `logout()` as shown below:

```swift
// [ 📄 ContentView.swift ]

// [ More code here ]

  func logout() {
    Auth0
      .webAuth()
      .clearSession { result in
        switch result {
          case .success:
            self.isAuthenticated = false
            // 👇🏽👇🏽👇🏽 New line of code here!
            self.userProfile = Profile.empty
            // 👆🏽👆🏽👆🏽

          case .failure(let error):
            print("Failed with: \(error)")
        }
      }
  }

// [ More code here ]
```


## Run the App Again

📺 [The _Run the App Again_ section of the video](https://www.youtube.com/watch?v=xOBoLegDmTw&t=2566s)

Run the app and confirm that the changes work. When you log in, you should see the user’s name, email address, and picture:

![The app’s “logged in” screen, featuring the text “Logged in” and displaying the user’s picture, name, and email address.](https://images.ctfassets.net/23aumh6u8s0i/1zYLUYAU3fdbLLde9PmhCN/90854331950e7557fbcc52db5bcb7379/logged_in_screen.png)

Congratulations, and high-fives and handshakes all around! You’ve taken a SwiftUI app and given it the ability to authenticate users with Auth0.


## Next Steps

SwiftUI is an expansive topic; we only scratched its surface in this tutorial. For your next steps in exploring it, you might want to look at these valuable resources:

- [SwiftUI by Example](https://www.hackingwithswift.com/quick-start/swiftui)
- [Your First SwiftUI App](https://www.youtube.com/watch?v=VlhcNR7Qrno)
- [Stanford University’s “Developing Applications for iOS” course for Spring 2021](https://www.youtube.com/playlist?list=PLpGHT1n4-mAsxuRxVPv7kj4-dQYoC3VVu)

📺 Last but not least, the video ends with [closing remarks and a quick accordion number](https://www.youtube.com/watch?v=xOBoLegDmTw&t=2645s)!

Get Started with iOS Authentication using SwiftUI, Part 2: User Info, ID Tokens, and JWTs

Learn how to add authentication (login and logout) to iOS apps built with SwiftUI with Auth0 and the Auth0.Swift package.

Get Started with iOS Authentication using SwiftUI, Part 1: Login and Logout

A step-by-step guide to leveraging OAuth 2.0 Refresh Tokens in an iOS app built with Swift and integrated with Auth0.

Using a Refresh Token in an iOS Swift App

poovamraj

I'm a senior software engineer at Auth0. From Rust to Kotlin, Java to JavaScript, I love exploring new languages, technologies, and frameworks. Away from the screen, you can find me in the Alps hiking.

Senior Software Engineer

Poovamraj Thanganadar Thiagarajan

We added support for hooks and rewrote it in TypeScript, made API improvements, improved Expo, Android, and iOS integration, and we think you’ll like it.

**We’re excited to announce the general availability of version 3.0 of our React Native SDK!** In this latest version, we’ve transformed our [`react-native-auth0` SDK](https://github.com/auth0/react-native-auth0) to work with two goals in mind:

* To work with the latest and greatest version of React Native, and 
* To create improvements to make your life as a developer easier. 

Read on to find out more about the new version of the SDK!


## What Changed?

We wanted to improve your developer experience and let you focus on what your applications do. We listened to your feedback, made changes to remove the obstacles that were getting in your way, and cut out the confusing parts that were slowing you down.

In this new version of the SDK, we made the following changes:

**100% support for hooks.** You’ve been asking for access to our authentication APIs (such as login via SMS, email, and so on) through hooks. That makes sense — after all, the general consensus is that React hooks generally make for more concise code that’s easier to read and maintain. So we went “all in”: our SDK now has 100% support through hooks! (And yes, you can still use it “the old way” too!)

**Improved `user` object and credentials.** The `User` object (available through our hooks API) isn’t static anymore and doesn’t just capture a snapshot of the user’s information at the moment of login. Instead, it dynamically updates to reflect changes to the user in real time. You can now force-refresh the user credentials, check their validity, and you can do so using either hooks or classes.

**Expo improvements.** The SDK now seamlessly integrates into any Expo project with a single line of configuration. You just specify the domain, and the SDK automatically generates the other configuration lines. We’ve also raised the minimum supported version of Expo to a more stable version (currently v48).

**Completely rewritten in TypeScript.** This allows us to take advantage of TypeScript’s type safety and removes any confusion about what data you provide to and receive from the SDK’s methods. (It also has the side benefit of making the SDK easier to maintain and update, which we believe will provide future benefits for you.)

**Improved Android/iOS interoperability.** We switched from React Native’s Android and iOS SDKs for web authentication to our own SDKs, which we use in the `Auth0.Android` and `Auth0.Swift` packages. Ours are battle-tested, more reliable, and less buggy, which provides your users with a better login/logout experience.


## Requirements

Naturally, you’ll need an Auth0 account to use the SDK. <a href="https://a0.to/blog_signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">You can sign up for a free account here;</a> the free version supports unlimited login/logout for up to 7,000 users and ten applications.

### Which versions of React Native are supported?

Version 3 of our React Native SDK targets apps using React Native version `0.60.5` and up.

### Is Expo supported?

This SDK _is_ compatible with Expo [custom development client](https://blog.expo.dev/introducing-custom-development-clients-5a2c79a9ddf8) and [EAS (Expo Application Services)](https://expo.dev/eas) builds. 

⚠️ Please note that the SDK is _not_ compatible with the [Expo Go](https://expo.dev/client) app because of the SDK’s use of custom native code.

### Which versions of Android and iOS are supported?

Version 3 of our React Native SDK supports the following mobile platform versions:

* **Android SDK 28, also known as “Android 9” or “Pie” (or later).** Android 9 was released in August 2018. 84% of devices active in the Play Store at the time of writing (August 2023) will run applications targeting this Android version. The oldest phones that support this version of Android date back to late 2017.
* **iOS 13 (or later).** iOS 13 was released in September 2020. As of the end of February 2023, almost 88% of iOS users were running iOS 16, with nearly 12% running iOS 15. iOS 14 users accounted for about 0.2% of users, while users of iOS 13 and earlier comprised the remaining 0.3%. The oldest iPhones that will run iOS 13 are the 6S and 6s Plus, which date back to 2015. Simply put, you’re not really leaving anyone behind by setting iOS 13 as the oldest supported version.


## How to Find Out More

* [**The `react-native-auth0` GitHub repository.**](https://github.com/auth0/react-native-auth0/) You can find the code here, as well as more than enough documentation to get started using the SDK — it’s all in the README file.
* [**The migration guide.**](https://github.com/auth0/react-native-auth0/blob/master/MIGRATION_GUIDE.md) This document covers the improvements that we made going from version 2 to version 3, changes that might break your current implementations, and changes to the format for callback URLs. If you’re working with projects based on the v2 SDK, make sure you read this.
* **Quickstarts.** The fastest way to create a new project that uses the Auth0 React Native SDK is to use a quickstart. We have a [**React Native quickstart**](https://auth0.com/docs/quickstart/native/react-native/interactive) and an [**Expo quickstart**](https://auth0.com/docs/quickstart/native/react-native-expo/interactive).
* **Sample projects.** These sample projects will help you get acquainted with the Auth0 React Native SDK in general and version 3 in particular:
	* [Login/logout app using React components](https://github.com/auth0-samples/auth0-react-native-sample/tree/master/00-Login)
	* [Login/logout app using React hooks](https://github.com/auth0-samples/auth0-react-native-sample/tree/master/00-Login-Hooks)
	* [Login/logout app using Expo](https://github.com/auth0-samples/auth0-react-native-sample/tree/master/00-Login-Expo)
* [**Code examples.**](https://github.com/auth0/react-native-auth0/blob/master/EXAMPLES.md) This is a collection of code snippets that shows you how to perform specific tasks using the SDK.


## Summary

We made version 3 of the React Native for Auth0 SDK based on your feedback to improve the developer and user experiences. With support for hooks, better integration with both Android and iOS, strong typing support, and fewer bugs, we’re sure you’ll enjoy working with this version!

Introducing Auth0 React Native SDK 3.0!

deepu-sasidharan

Deepu is a polyglot developer, Java Champion, and OSS aficionado. He mainly works with Java, JS, Rust, and Golang. He co-leads JHipster and created the JDL Studio and KDash. He's a Principal Developer Advocate at Okta. He is also an international speaker and a published author.

Deepu K Sasidharan

Deploy a cloud-native Java Spring Boot microservice stack secured with Auth0 on Amazon EKS using Terraform and Kubernetes.

Deploy Secure Spring Boot Microservices on Amazon EKS Using Terraform and Kubernetes

andres

I’ve been at Auth0 since 2017. I’m currently working as a Director, Product Management 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.

Director, Product Management

Andrés Aguiar

Join us at KubeCon + CloudNativeCon Europe on April 17th, 2023, for the official launch of OpenFGA v1.0

We’ve been talking to hundreds of developers who consistently tell us that they want to change how authorization is implemented in their applications. Authorization logic is embedded in the code and implemented differently in each service. It’s not flexible enough to define complex policies or finer-grained authorization. They struggle with load at scale. The existing RBAC/ABAC solutions can’t handle this complexity. That’s why we built OpenFGA.

We are thrilled to announce the release of [OpenFGA](https://openfga.dev) v1.0, a modern, flexible authorization system inspired by [Google's Zanzibar](https://zanzibar.academy). OpenFGA, designed for reliability and low latency at scale, has been embraced by the developer community since its open-sourcing in June 2022. As a Cloud Native Computing Foundation (CNCF) Sandbox Project, OpenFGA is having a significant impact in the world of authorization.

## OpenFGA v1.0: A Host of Enhancements

OpenFGA v1.0 brings a wealth of improvements since it was open sourced, raising the bar for authorization systems and providing developers with the tools they need to create secure, scalable applications. Here's a rundown of the new features:

1. Enhanced Authorization Model Language: OpenFGA v1.0 offers a [significantly improved](https://openfga.dev/docs/modeling/migrating/migrating-schema-1-1) language for defining authorization models, making them easier to read and author.
2. ListObjects API: This [new API](https://openfga.dev/docs/interacting/relationship-queries#listobjects) lets you retrieve all resources that a user can access based on the defined authorization policies, greatly simplifying auditing and access controls.
3. Elevated Observability: OpenFGA v1.0 takes [observability to new heights](https://openfga.dev/docs/getting-started/setup-openfga/docker#telemetry) with Open Telemetry tracing, Prometheus metrics, and prof profiles, providing insights into your authorization system's performance.
4. Effortless Deployment: Deploying OpenFGA to Kubernetes has never been easier, thanks to [official Helm chart](https://artifacthub.io/packages/helm/openfga/openfga) support. Get your Kubernetes cluster provisioned with just one command.
5. Postgres Storage Adapter Performance Boost: OpenFGA v1.0's Postgres storage adapter is supercharged, ensuring rapid performance and seamless scalability.
6. New Python SDK: A brand-new [Python SDK](https://pypi.org/project/openfga-sdk/) makes it even more convenient for Python developers to integrate OpenFGA into their projects.
7. Batching support in SDKs: OpenFGA v1.0's enhanced SDKs support batching queries, providing greater efficiency when making authorization requests, available for [JavaScript](https://github.com/openfga/js-sdk#batch-check) and [.NET](https://github.com/openfga/dotnet-sdk), [Go](https://github.com/openfga/go-sdk) coming pretty soon!

## Experience OpenFGA v1.0 at KubeCon + CloudNativeCon Europe, April 17, 2023

Mark your calendars and join us at KubeCon + CloudNativeCon Europe for the official launch of OpenFGA v1.0. Be among the first to discover the future of authorization systems and learn how OpenFGA can transform your cloud deployments and bolster your application security.

You’ll be able to connect with the OpenFGA team in different ways:

* Find us at Kiosk #27 in the Project Pavilion in the afternoons.
* Join the [OpenFGA project meeting](https://kccnceu2023.sched.com/event/1JWSb) on April 18, 9:30 AM CST in Room D406, Congress Center
* Participate in the Cloud Native Authorization Birds of a Feather meeting on April 21st from 11 AM - 12:30 PM CST. You can register [here](https://kccnceu2023.sched.com/event/1KW9e).

## Join us!

An open-source project is only as good as its community, so we are extending a warm welcome to everyone who wants to get involved. 

The project already has more than 30 contributors from multiple companies, and it’s being deployed in production by many of them.

The community has contributed a [MySQL Storage Adapter](https://github.com/openfga/openfga/pull/210), SDKs for [ASP.NET Core](https://github.com/Hawxy/Fga.Net), [Elixir](https://github.com/msutkowski/fga-elixir-sdk),  [Kotlin](https://github.com/Ozee-io/fga-kotlin-sdk) and integrations with [Quarkus](https://github.com/quarkiverse/quarkus-zanzibar), [Open Policy Agent](https://github.com/thomasdarimont/custom-opa-openfga), [Keycloak](https://github.com/embesozzi/keycloak-openfga-workshop), [Kratos](https://github.com/tx7do/kratos-authz) and [SCIM](https://github.com/SUSE-Skyscraper/openfga-scim-bridge).

You can help by simply trying the product, providing feedback, and engaging with other OpenFGA users in [Discord](https://discord.gg/6xzMMuU8YR) / [Github Discussions](https://github.com/orgs/openfga/discussions), attending our [monthly meetings](https://github.com/openfga/community/blob/main/community-meetings.md), or [contributing](https://github.com/openfga/.github/blob/main/CONTRIBUTING.md) to the project.

Find out more by checking out the Github repository [https://github.com/openfga/openfga](https://github.com/openfga/openfga), and learn how to use it in our [documentation](http://openfga.dev). Keep up to date with the latest news by following us on [Twitter](https://twitter.com/openfga).


Announcing OpenFGA v1.0: A New Milestone in Cloud Native Authorization Systems

Learn how to build a basic app using Android’s Jetpack Compose UI toolkit.

Get Started with Jetpack Compose Authentication, Part 1: Jetpack Compose Basics

Learn how to add authentication to a basic Jetpack Compose app.

Get Started with Jetpack Compose Authentication, Part 2: Adding Authentication

Ruchita Shah

Ruchita is a Product Marketer for Okta’s Customer Identity products. With an engineering and product marketing background, she is focused on showcasing how organizations can create secure and seamless digital experiences for their end users using Okta’s identity products. She spends her spare time hiking, reading and watching Formula1

Senior Product Marketing Manager, Customer Identity

The Auth0 React Native SDK v2.16.0 improves both developer and the user experience

We’re excited to announce the released version 2.16.0 to our Auth0 React Native SDK. Major features we delivered in this release include:

* Expo support
* Hooks API
* Secure Credentials Manager

## Support for Expo

Expo is a popular framework that adds a suite of features to React Native apps. We have added support for this tooling to make it much easier to work with our SDK in conjunction with Expo, as it provides a [number of benefits](https://www.mozestudio.com/journal/what-is-expo-and-why-it-matters-for-app-development/) when used to build React Native apps.

We added this support in response to growing customer demand. We received various feedback across our channels that indicated to us that this would be a valuable addition to our SDK. In an excellent demonstration of the power of open-source software, our implementation actually started life as a pull request from the community, which was able to review, tidy up, and merge into our codebase for the benefit of others. 

Given Expo’s growing popularity among the React Native community, it was clear this was an opportunity to provide first-class support in the SDK. To that end, we also now provide an [Expo-specific quickstart](https://auth0.com/docs/quickstart/native/react-native-expo/interactive) in addition to our standard React Native quickstart so that developers can get up and running even quicker.

## New React Hooks API

This release adds support for using the SDK using[ React Hooks](https://reactjs.org/docs/hooks-intro.html). This was primarily driven by our own desire to modernize the SDK and provide an API that felt more natural to modern React developers. React Hooks have been in React Native 0.59 (released around March 2019). Our hooks wrap our pre-existing WebAuth classes, so the developer can choose to use Hooks or to continue using the provided classes should they wish.

In addition, we updated our [React Native quickstart](https://auth0.com/docs/quickstart/native/react-native/interactive) to use the new Hooks API by default.

![New React Hooks API](https://images.ctfassets.net/23aumh6u8s0i/5mdxN3EK60eYe1LS3E9jP5/90150f525eea0d0209ba87c50753d14d/react-sdk.png)

### How to use the new Hooks API

Previously, the developer could instantiate a class and use the properties and methods provided to implement authentication into their apps.

```js
import Auth0 from 'react-native-auth0';
import jwt_decode from 'jwt-decode';
 
const auth0 = new Auth0({
     domain: 'YOUR_AUTH0_DOMAIN',
     clientId: 'YOUR_AUTH0_CLIENT_ID',
});
  
const App = () => {
 
   let [user, setUser] = useState(null);
 
   const onLogin = () => {
       auth0.webAuth
           .authorize({
               scope: 'openid profile email'
           })
           .then(credentials => {
                 const payload = jwt_decode(credentials.idToken);
                 setUser(payload)
           })
           .catch(error => console.log(error));
   };
 
   return (
       <View>
         {!user && <Button onPress={onLogin} title="Log in" />}
         {user && <Text>Logged in as {user.name}</Text>}
       </View >
   );
}
 
export default App;
```

Now, the developer can use Hooks to implement login, providing an idiomatic way to implement reactive code in a React Native app using function components:

```js
// App.js
import {Auth0Provider} from 'react-native-auth0';

const App = () => {
  return (
    <Auth0Provider domain="YOUR_AUTH0_DOMAIN" clientId="YOUR_AUTH0_CLIENT_ID">
      {/* YOUR APP */}
   </Auth0Provider>
 );
};
```
```js
// Component.js
const Component = () => {
    const {authorize, user} = useAuth0();
   
    const login = async () => {
      await authorize();
    };
   
    return (
      <View>
        {!user && <Button onPress={login} title="Log in" />}
        {user && <Text>Logged in as {user.name}</Text>}
      </View>
    );
   };   
```

## Secure Credentials Manager

Up until this release, the developer was in charge of storing and managing the tokens that were returned to the app from Auth0 without any assumptions from the SDK as to how and where tokens were stored. Now, we provide a built-in secure credentials manager that automatically stores these tokens.

This was another feature that was driven by community asks but one that makes a lot of sense if we’re interested in making things as frictionless for the developer as possible. We had a number of requests across our channels for this, and we’re pleased to be able to provide it as a first-class addition to the SDK

This mechanism uses the thoroughly tested credentials manager instances provided by [Auth0.Swift](https://github.com/auth0/Auth0.swift/) and [Auth0.Android](https://github.com/auth0/Auth0.Android).

Automatically refreshes the access token when it expires.

Automatically stores and clears tokens when using the Hooks API.

Support for platform-specific Biometric Authentication

## Summary

The Auth0 React Native SDK v2.16.0 improves both developer and the user experience. On the one hand, it provides flexibility for developers to be up and running in less time. On the other hand, it provides a more secure credentials manager that can automatically manage tokens.

For further reading: [Introducing the Auth0 Flutter SDK](https://auth0.com/blog/introducing-the-auth0-flutter-sdk/)

Introducing Auth0 React Native SDK v2.16.0

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.

Andrea Chiarelli

Learn how to call a protected API from your .NET MAUI application.

Call a Protected API from a .NET MAUI App

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. 

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

I stream, blog, and make youtube videos about tech stuff. I love coding, I love AI, and I love building stuff!

Juan Cruz Martinez

Learn about the essential features of the Auth0 Flutter SDK and how it helps developers build and secure Flutter iOS and Android applications.

Today we are announcing the release of the [Auth0 Flutter SDK](https://pub.dev/packages/auth0_flutter), a new SDK that makes it easy to secure Flutter applications with Auth0. Whether you need to secure access to an iOS or Android application, the Auth0 Flutter SDK got you covered!

The new Flutter SDK builds on a strong foundation by wrapping our existing and robust [Auth0.Android](https://github.com/auth0/Auth0.Android) and [Auth0.swift](https://github.com/auth0/Auth0.swift) libraries while focusing on the developer experience first.

Our SDK team optimized the Auth0 Flutter SDK for quick integration into your applications and for flexibility to accommodate simple and advanced use cases.

Since the introduction of [Flutter 3](https://medium.com/flutter/introducing-flutter-3-5eb69151622f), the framework allows for building cross-platform applications, extending from mobile applications to desktop applications and platforms. Our SDK allows for extension in such platforms by leveraging federated plugins, which means you can easily add support for other platforms without forking the SDK.

## Auth0 Flutter SDK Features

The new SDK offers features for multiple use-cases and complexity, going from magically getting the job done to providing a rich set of APIs enabling you to build your authentication flow per your specific requirements.

Let's explore the essential features of the Auth0 Flutter SDK that enable developers to do more:

- ⚡️ Quick implementation of login, logout, and automatic storage and renewal of tokens functionality into Flutter apps using WebAuth and the [Auth0 Universal Login](https://auth0.com/docs/authenticate/login/auth0-universal-login) page.
- ⚙️ For more advanced use-cases, developers have access to the [Authentication API](https://pub.dev/documentation/auth0_flutter/latest/auth0_flutter/AuthenticationApi-class.html), which at the time of release supports:
	- Logging in with a username or email and password
	- Signing up new users
	- Getting user information from `/userinfo`
	- Renew tokens
	- Reset passwords
- 🔐 Auth0 provides a default instance of [Credentials Manager](https://pub.dev/documentation/auth0_flutter/latest/auth0_flutter/DefaultCredentialsManager-class.html) that automatically stores the user's credentials. If you need your own solution for handling credentials, you can create your own [custom credentials manager](https://pub.dev/documentation/auth0_flutter/latest/auth0_flutter/CredentialsManager-class.html).
- ➕ And more [advanced features](https://pub.dev/packages/auth0_flutter#advanced-features) like accepting user invites, login into organizations, and bot detection.

## Requirements

The Auth0 Flutter SDK doesn't require any other library to work. However, there are SDK version and platform requirements for your project:

<table style="width:100%" cellspacing="2" cellpadding="5">
    <thead>
        <tr style="border-bottom: solid 1px">
            <td>**Flutter**</td>
            <td>**Android**</td>
            <td>**iOS**</td>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>SDK 3.0+</td>
            <td>Android API 21+</td>
            <td>iOS 12+</td>
        </tr>
        <tr>
            <td>Dart 2.17+</td>
            <td>Java 8+</td>
            <td>Swift 5.3+</td>
        </tr>
        <tr>
            <td></td>
            <td></td>
            <td>Xcode 13.x / 14.x</td>
        </tr>
    </tbody>
</table>

Check the [project on GitHub](https://github.com/auth0/auth0-flutter/tree/main/auth0_flutter#requirements) to for the most up-to-date set of requirements.

## Installing the SDK

The Auth0 Flutter SDK is distributed via [pub.dev](https://pub.dev/packages/auth0_flutter).

To add the SDK, run the following command from the root directory of your project:

```bash
flutter pub get auth0_flutter
```

## Adding Universal Login to Your Flutter Application

Adding the full-featured [Auth0 Universal Login](https://auth0.com/docs/authenticate/login/auth0-universal-login) authentication page to your application is easy with the SDK.

Please explore the [Flutter Quickstart guide](https://auth0.com/docs/quickstart/native/flutter/interactive) to see in detail how to set up your Flutter application to use the Auth0 SDK. For now, let's take a quick peak at how the Flutter SDK integration goes!

### Add login to your app

Integrate Auth0 Universal Login in your Flutter app by using the Auth0 class. Redirect your users to the Auth0 Universal Login page using `webAuthentication().login()`. This is a `Future` and must be awaited for you to retrieve the user's tokens.

```dart
await auth0.webAuthentication(scheme: 'YOUR CUSTOM SCHEME').login();
```

### Add logout to your app

Logging out users is as easy as calling the Auth0 Flutter SDK `webAuthentication().logout()` function. The `logout()` function is responsible for calling the `logout` endpoint to clear their login session and to clear the user login state from the device session.

```dart
await auth0.webAuthentication(scheme: 'YOUR CUSTOM SCHEME').logout();
```

## Next Steps

There are a lot of options to work with with the SDK, and in this post, we only barely scratch the surface of it. If you want to learn more about the SDK, please check out the [quick start guide](https://auth0.com/docs/quickstart/native/flutter/interactive) and the [SDK documentation](https://pub.dev/packages/auth0_flutter).

Thanks for reading!

Introducing the Auth0 Flutter SDK

Learn how to use user and app metadata in Auth0 user profiles to store additional information about your users.

Working with Auth0 User and App Metadata in iOS Apps

Working with Auth0 User and App Metadata in Android Apps

A step-by-step tutorial on using Auth0 and Swift to implement login/logout and use user metadata in iOS apps.

Get Started with iOS Authentication using Swift and UIKit

wern ancheta

Hi! I’m Wern Ancheta. I’m a Web Developer from San Fernando City, La Union, Philippines. I love building things for the web and sharing the things I’ve learned through writing. When I’m not coding or learning something new, I enjoy watching anime and playing video games.

Guest Author

Wern Ancheta

Learn how to add authentication to React Native Android apps with Auth0.

Get Started with Auth0 Authentication in React Native Android Apps

Learn how to add authentication to React Native iOS apps with Auth0.

Get Started with Auth0 Authentication in React Native iOS Apps

The newly released JHipster Native blueprint allows you to generate Spring Boot projects with Spring Native support.

Introducing Spring Native for JHipster: Serverless Full-Stack Made Easy

Learn about the three kinds of information stored with each Auth0 user account and how to access them in your Android apps.

Working with Auth0 User Profile Information and Metadata in Android Apps

bruno-krebs

I am passionate about developing highly scalable, resilient applications. I love everything from the database, to microservices (Kubernetes, Docker, etc), to the frontend. I find amazing to think about how all pieces work together to provide a fast and pleasurable experience to end users, mainly because they have no clue how complex that "simple" app is.

R&D Content Architect

Bruno Krebs

Learn how to integrate your Android application with a backend API.

Android Tutorial: Building and Securing Your First App (Part 2)

Learn how to develop and secure Android applications with ease.

Android Tutorial: Building and Securing Your First App (Part 1)

matthew-casperson

Technology enthusiast since my first C64. I love writing about new ideas and working with great people.

Product Manager at Octopus Deploy

Matthew Casperson

Learn how to create a natively compiled Quarkus HTTP API secured with Auth0.

Cloud computing has seen a shift from traditional Java deployments to application servers like Tomcat to highly dynamic environments such as serverless and container orchestration platforms like Kubernetes.

Many of the benefits of these new cloud platforms rely on their ability to quickly spin application instances up to meet additional demand and restart applications to adapt to infrastructure changes like operating system upgrades or virtual machine provisioning.

Deploying Java to these environments has been a challenge, though, largely due to the amount of time it takes even a basic Java web application to start, called the cold boot time. It is not uncommon to have to wait 30 seconds or more before your application can begin serving traffic, which becomes a problem on platforms that scale down to zero waiting for incoming traffic and expect to quickly launch an application to process a request.

[Quarkus](https://quarkus.io/) is a container native platform that addresses many of these performance issues, and in this blog post, we'll take a look at a simple Quarkus web application exposing a REST endpoint protected by Auth0.

## What is Quarkus

Quarkus has been designed to address the needs of serverless and container environments by reducing startup times and memory consumption. Perhaps the most exciting thing about Quarkus is its tight integration with GraalVM to allow applications to be compiled into native binaries.

Quarkus integrates with a huge range of libraries, giving developers access to many familiar platforms and allowing for the migration of existing code bases. These libraries are selected or customized to run seamlessly on Quarkus and to be able to take advantage of native compilation.

Of course, authentication is a central requirement of any modern web application, and Quarkus has out of the box support for OAuth, which in turn can be integrated into Auth0.

## The Sample Application Prerequisites

The source code for the sample application can be found on [GitHub](https://github.com/mcasperson/auth0quarkusdemo).

To build the source code, you'll need to have JDK 11, which is available from many sources, including [OpenJDK](https://openjdk.java.net/install/), [AdoptOpenJDK](https://adoptopenjdk.net/), [Azul](https://www.azul.com/downloads/), or [Oracle](https://www.oracle.com/au/java/technologies/javase-jdk11-downloads.html).

The source code includes the [Maven wrapper](https://github.com/takari/maven-wrapper), so calls to `mvnw` will download Maven for you if it is not already installed.

To compile a native binary, the latest version of [GraalVM](https://www.graalvm.org/downloads/) targeting Java 11 is required. It is important to install the Java 11 version of GraalVM, as opposed to the Java 8 or 16 versions, as this is the only version that will compile a native binary due to [this bug](https://github.com/quarkusio/quarkus/issues/15903). 

In addition, the [native image](https://www.graalvm.org/reference-manual/native-image/) component needs to be installed with the command:

```bash
gu install native-image
```

To build and run the Docker image [mcasperson/auth0quarkusnative](https://hub.docker.com/r/mcasperson/auth0quarkusnative), [Docker](https://docs.docker.com/get-docker/) must be installed.

The docker image can be run with the following command, where `AUTH0SECRET` is set to the **Client Secret**, `AUTHSERVER` is set to the **Domain**, and `CLIENTID` is set to the **Client ID** of your [Auth0 application](https://auth0.com/docs/applications):

```bash
docker run \
    --env AUTH0SECRET=xxxx \
    --env AUTHSERVER=https://your.auth0.domain \
    --env CLIENTID=xxxx \
    -p 8080:8080\
    mcasperson/auth0quarkusnative
```

## The Sample Application

We'll bootstrap our sample application with the online [project builder](https://code.quarkus.io/). Our project will make use of the RESTEasy JAX-RS and OpenID Connect extensions to expose HTTP endpoints and integrate with an authentication service.

Populate the **Group** and **Artifact** fields, and select **RESTEasy JAX-RS** and **OpenID Connect** from the list of extensions. Then click the **Generate your application** button to download the sample project:

![Project Builder](https://images.ctfassets.net/23aumh6u8s0i/p0NTCYkX3iuBaovL2eaUg/de2c35d9facd0decbae37db4e0039225/projectbuilder.jpg)

### The REST endpoints

We'll start with the `GreetingResource` class, which we have modified slightly from the supplied template. The complete class is shown below:

```Java
package org.matthewcasperson;

import io.quarkus.oidc.IdToken;
import org.eclipse.microprofile.jwt.JsonWebToken;

import javax.inject.Inject;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;
import java.util.Optional;

@Path("/")
public class GreetingResource {

    @Inject
    @IdToken
    JsonWebToken idToken;

    @GET
    @Produces(MediaType.TEXT_HTML)
    public String hello() {
        return
                "<html>\n" +
                "    <body>\n" +
                "        <h1>Hello " + idToken.getClaim("email") + "</h1>\n" +
                "    </body>\n"+
                "</html>\n";
    }
}
```

This class is relatively simple. We annotate the class with the `@Path` JSX-RS annotation to indicate that it will respond to the root path:

```Java
@Path("/")
public class GreetingResource 
```

Inside the class, we use CDI annotations to inject an instance of the OpenID ID token:

```Java
    @Inject
    @IdToken
    JsonWebToken idToken;
```

We then have a method that returns a simple HTML page embedding the `email` claim contained by the ID token:

```java
    @GET
    @Produces(MediaType.TEXT_HTML)
    public String hello() {
        return
                "<html>\n" +
                "    <body>\n" +
                "        <h1>Hello " + idToken.getClaim("email") + "</h1>\n" +
                "    </body>\n"+
                "</html>\n";
    }
```

Anyone familiar with Java EE style application development will immediately recognize the JAX-RS and CDI annotations. By incorporating existing libraries, Quarkus applications provide a familiar environment for Java developers.

### The unit tests

We have a test in the `GreetingResourceTest` class. Originally this test verified that accessing the REST endpoint returned an HTTP 200 OK status code. Here we have updated the test to verify that the endpoint returns an HTTP 403 Unauthorized status code, which we expect because this test does not provide any authentication information:

```Java
package org.matthewcasperson;

import io.quarkus.test.junit.QuarkusTest;
import org.junit.jupiter.api.Test;

import static io.restassured.RestAssured.given;
import static org.hamcrest.CoreMatchers.is;

@QuarkusTest
public class GreetingResourceTest {

    @Test
    public void testHelloEndpoint() {
        given()
          .when().get("/")
          .then()
             .statusCode(403);
    }
}
```

### The properties file

To enable the population of the ID Token, we need to configure our application to protect our REST endpoints and configure the external authentication service that we trust to verify any users. Quarkus defines these settings in a file called `application.properties`, located in the `src/main/resources` directory. The complete file is shown below:

```properties
quarkus.http.port=${PORT:8080}
quarkus.oidc.auth-server-url=${AUTHSERVER:https://your.auth0.domain}
quarkus.oidc.client-id=${CLIENTID:xP2E7TJYaKQmh5EyFPYCmtGuIC3Drbez}
quarkus.oidc.credentials.secret=${AUTH0SECRET}
quarkus.oidc.application-type=web_app
quarkus.http.auth.permission.authenticated.paths=/*
quarkus.http.auth.permission.authenticated.policy=authenticated
quarkus.oidc.authentication.scopes=openid,profile,email
```

Let's break down the settings:

* `quarkus.http.port=${PORT:8080}` defines the HTTP port the application listens on. The value assigned here uses the `PORT` environment variable or a default value of `8080`.
* `quarkus.oidc.auth-server-url=${AUTHSERVER:https://your.auth0.domain}` defines the URL of the authentication server. For convenience, you can assign a default value for the domain (replace `your.auth0.domain` with your own Auth0 application domain), with the value able to be overridden via the `AUTHSERVER` environment variable.
* `quarkus.oidc.client-id=${CLIENTID:xP2E7TJYaKQmh5EyFPYCmtGuIC3Drbez}` defines the client ID, which again has been set with a default Auth0 client ID, with an override able to be defined via the `CLIENTID` environment variable.
* `quarkus.oidc.credentials.secret=${AUTH0SECRET}` defines the client secret from an environment variable. As this value should remain a secret, no default value has been provided.
* `quarkus.oidc.application-type=web_app` indicates that this application is a web application.
* `quarkus.http.auth.permission.authenticated.paths=/*` defines the paths to be protected, and in our the value matches all paths. The `authenticated` component of the key can be called whatever you want (for example, this key could have been called `quarkus.http.auth.permission.mygroup.paths` instead) and is used to match paths to the policy below.
* `quarkus.http.auth.permission.authenticated.policy=authenticated` ensures only authenticated users are able to access the protected paths. The `authenticated` component of the key matches the same name used in the `quarkus.http.auth.permission.authenticated.paths` key above.
* `quarkus.oidc.authentication.scopes=openid,profile,email` defines the scopes requested from the authentication provider. In particular, our web page displays the email address of the authenticated user, so we ensure that scope is defined here.

## Packaging the Application

To package the application, which will run the tests by default, we need to define the environment variables referenced by the properties file. Although the test does not contact the Auth0 servers, Quarkus will fail if any properties defined as environment variables with no default value can not be resolved, such as our `quarkus.oidc.credentials.secret` property.

Expose the environment variables with the following commands, where `AUTH0SECRET` is set to the **Client Secret**, `AUTHSERVER` is set to the **Domain**, and `CLIENTID` is set to the **Client ID** of your [Auth0 application](https://auth0.com/docs/applications):

```bash
export AUTH0SECRET=xxxxxxxxxxxx
export AUTHSERVER=https://your.auth0.domain
export CLIENTID=xxxx
```

From the directory containing the `pom.xml` file, package the application with the command:

```bash
./mvnw package
```

We can then run the application with the command:

```bash
java -jar target/quarkus-app/quarkus-run.jar
```

Open http://localhost:8080/ in your web browser. You will be redirected to the Auth0 login page, and once you supply the details of a valid user, you'll be redirected back to the web app where the email address of the authenticated user is displayed:

![Web App](https://images.ctfassets.net/23aumh6u8s0i/7ge4jCbvxTX0KrqzGg45Ks/ecb70697cdeebd8239d2b9c6d5eb5ee0/webapp2.jpg)

Note that for the Auth0 application to allow redirection back to applications running locally, the URL `http://localhost:8080` must be defined in the Allowed Callback URLs list:

![Callback](https://images.ctfassets.net/23aumh6u8s0i/BuqDQCnXARuHKoIcHa1CX/bc3998283f8cb05e919bc0e444937a40/callbacks.jpg)

## Compiling a Native Binary

On my (admittedly aging) Macbook Pro, the JAR file above booted in around 1.7 seconds. This is quite an achievement, given cold start times of over 30 seconds are not that uncommon with Java web apps.

But even this snappy load time can be improved by compiling our application to a native binary. Thanks to the tight integration between Quarkus and GraalVM, compiling a native binary can be done with the command:

```bash
./mvnw package -Pnative
```

The `-Pnative` argument builds the application with the `native` Maven profile, which was defined in the `pom.xml` file generated for us by the Quarkus project builder website.

Once compiled, our native binary can be run with the command:

```bash
./target/auth0quarkusdemo-1.0.0-SNAPSHOT-runner
```

On my laptop, the first run of the native binary booted in 0.9 seconds, the second run started in 0.5 seconds, and the third run took only 0.2 seconds. This is an amazing improvement, given we did nothing more than pass one argument to the build command.

With these load times, we can realistically load our Java application in a serverless environment and quickly scale from zero to respond to the first request.

More importantly, though, is the fact that native compilation is a core tenant of the Quarkus platform. Each library promoted by Quarkus is expected to support native compilation, and bugs relating to native compilation appear to be given high priority by the Quarkus team. This provides developers with some degree of confidence that they can continue to build natively compiled applications with Quarkus and not run into a roadblock that will break their builds.

## Conclusion

Quarkus provides Java developers with a platform to build cloud-native applications they can deploy to environments that Java can struggle in, such as serverless and Kubernetes. With drop-in support for Open ID, Quarkus apps can be easily integrated with an Auth0 application. And native compilation provides lightning fast boot times with little effort from developers.

Quarkus and Auth0 Integration

michael-bui

I'm a software developer with a background in consulting and experience in technical leadership roles. The majority of my career has been with using .NET to build applications across the full-stack and for mobile, desktop, and web. My main area of interest is in agile software development and building cross-platform applications using technologies like Flutter and Xamarin.Forms.

These days I do more work using Flutter. Besides using it professionally to build applications, I've done a talk at a meetup, maintain a blog where I post about Flutter in <a href="https://dexterx.dev">DexterX</a> and contribute to and maintain various open-source projects.

Sofware Developer

Michael Bui

Update the Flutter wishlist app to use Auth0 authentication so that the user has to log in and the app accesses a secured API.

Build a Flutter Wishlist App, Part 3: Finishing the App with User Authentication and a Secured API

Implement the ability to view the wishlist, as well as add, edit, and delete items from the wishlist.

Build a Flutter Wishlist App, Part 2: Adding CRUD Functionality to Your App

Auth0 now supports native login for Facebook, which improves UX and complies with newly-tightened Facebook and Apple policies.



These days, it's common for users accessing websites and applications from a web browser to authenticate with social identity providers such as Google or Facebook. Offering social login as an option goes a long way toward improving user experience. In fact, in a recent survey, [86% of users reported being bothered by having to create new accounts on websites, and 77% said that "social login is a good solution that should be in any site.](https://auth0.com/learn/social-login/)"

On mobile devices, social identity providers usually have their own applications (e.g., Facebook, Twitter), and some of them actually provide the operating system (e.g., Google, Apple). In the latter cases, users can use single sign-on (SSO) with a native UI instead of reauthenticating in the browser. This makes for a cleaner, simpler user experience.

Auth0 already supports native login for Apple ([Sign In with Apple](https://auth0.com/docs/connections/nativesocial/apple)), and we are excited to announce that we now support [native login for Facebook](https://auth0.com/docs/connections/nativesocial/facebook) as well. This allows for authentication using the identity of the user who is logged into the Facebook application installed on the device. Auth0 customers who implemented this flow immediately saw an improvement in how their users were able to authenticate with Facebook:

<include src="BigQuote" quoteText="By enabling native social authentication, our app's Facebook login times have been reduced by 50% compared to web authentication. And successful Facebook logins in our app have increased by 16%." quoteAuthor="Eric Jensen, Principal Engineer, Kiva"/>

> Learn how [Kiva eliminated 22,000 lines of legacy code](https://auth0.com/case-studies/kiva-implements-auth0-rules-mfa/) by implementing Auth0.

## Enhanced User Experience

Compass is a leading national real estate technology company that provides tools and services to help real estate agents grow their businesses and better serve their clients. As one of the largest groups of small business owners in the country, real estate agents utilize the end-to-end Compass platform to improve their productivity and manage their businesses more effectively. Compass currently powers over 18,000 real estate agents across 150+ U.S. cities, who were responsible for over $91 billion in real estate transactions in 2019.

Compass's suite of software tools acts as an operating system for real estate agents, making them more efficient by optimizing their workday, pricing properties more accurately, determining the best time to list, and more. The platform also integrates listings, transactions, and individual client data, giving agents personalized recommendations and insights. This enables agents to tailor their services to the specific needs of each client.

To help agents collaborate with their clients and stay productive even when they're not in front of their laptops, Compass provides iOS and Android apps. They've implemented login with Google, Facebook, and Apple to reduce friction for users. You can see the Facebook login experience in action below:

![Facebook Login 1](https://images.ctfassets.net/23aumh6u8s0i/17jqJUyNCs3a8uIDYVCUzS/df8f1f1d8c7d03fa3f626418dc99f2d6/facebook_login_1)

![Facebook Login 2](https://images.ctfassets.net/23aumh6u8s0i/1gatAU30RSdraoE2tQIrGl/ae58ad5342a3c13e12890ef705d2dbe1/facebook_login_2)

In Android, a popup is displayed where users can confirm their identity and log in. In iOS, the flow is not quite as seamless since the Facebook app is opened, but this gives the end user a clear understanding of what is happening and reassures them that the Facebook app furnished the credentials. 

## Complying With Facebook and Apple Policies

In the past months, several social login providers have been tightening up their requirements to integrate applications with their authentication frameworks. 

* [Facebook's Platform Policy](https://developers.facebook.com/policy#login) states: _"Native iOS and Android apps that implement Facebook Login must use our official SDKs for login."_

* [Apple's application guidelines](https://developer.apple.com/app-store/review/guidelines/#data-collection-and-storage) read: _"An app may not store credentials or tokens to social networks off of the device and may only use such credentials or tokens to directly connect to the social network from the app itself while the app is in use."_

## How Does It Work?

Based on the requirements described above, we collaborated with Facebook to design a solution that will let us authenticate Facebook users in native apps while complying with Apple's rules. The image below shows a high-level description of the flow:

![Facebook Diagram](https://images.ctfassets.net/23aumh6u8s0i/vxr56C8bJdZnGChZqASyV/bcf442508c76064ce8d7ba8974bc5b8d/diagram_facebook)

1. The application logs in with Facebook using the Facebook SDK. This returns a Facebook access token.

2. The native application requests the user profile using the Facebook API or corresponding call in the Facebook SDK.

3. The application exchanges the access token for a [session info access token](https://developers.facebook.com/docs/facebook-login/access-tokens/session-info-access-token). This is a token that can only be used to validate that the user created a session, not to act on behalf of the user or retrieve the user profile.

4. The application calls Auth0's `/oauth/token` endpoint, sending the session info access token and the user profile data.

5. Auth0 calls the [debug_token](https://developers.facebook.com/docs/graph-api/reference/v7.0/debug_token) endpoint to validate that the user initiated a session with Facebook. 

You can read more and see the payload for each API call in our ["Add Facebook Login to Native Apps" docs](https://auth0.com/docs/connections/nativesocial/facebook).

## Get Started

You are only a few steps away from greatly simplifying how users log into your mobile applications. Check out our [Android](https://auth0.com/docs/quickstart/native/android-facebook-login) and [Swift](https://auth0.com/docs/quickstart/native/ios-swift-facebook-login) quickstart guides to learn how to integrate native login with Facebook using our updated [Android SDK](https://github.com/auth0/Auth0.Android) and [Swift SDK](https://github.com/auth0/Auth0.swift).

<include src="asides/AboutAuth0" />


Improving Login With Facebook User Experience With Native Login

fikayo-adepoju

Fikayo Adepoju is a Full-stack developer, technical writer and tech content creator proficient in Web and Mobile technologies and DevOps with over 10 years experience developing scalable distributed applications. With over 40 articles written for CircleCI, Twilio, Auth0 and The New Stack blogs and also on his personal Medium page, he loves to share his knowledge to as many developers as would benefit from it. You can also check out his video courses on <a href="https://www.udemy.com/user/fikayo-adepoju/">Udemy</a>.

Full-Stack Developer

Fikayo Adepoju

Learn how to leverage Vue.js and Electron to build and secure modern desktop applications.

Electron Tutorial: Building Modern Desktop Apps with Vue.js

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 tutorial we implement centralized logins for iOS both manually and using the Auth0 SDK.

Add Authentication To Your iOS Apps with Centralized Login

eHk3ciM

I am the Group Manager, Developer Content at Okta, and a Google Developer Expert in Web Technologies and Angular. I'm passionate about identity, authentication, constant learning, and developer communities. As a developer advocate, engineer, mentor, and international speaker, I love learning from and sharing with other inhabitants of the tech space.

Group Manager, Developer Content

Kim Maida

The IETF has released Best Current Practice (BCP) for OAuth 2.0 in native apps. Learn about it now.



**TL;DR:** In October, 2017, the [Internet Engineering Task Force (IETF)](https://www.ietf.org/) released the [Best Current Practices (BCP) when using OAuth 2.0 with native mobile applications](https://www.rfc-editor.org/rfc/rfc8252.txt). This BCP states that OAuth 2.0 authorization requests from native apps should _only_ be made through external user agents, primarily the user's browser. We'll discuss what this means for developers and users and any security considerations involved.

---

## OAuth 2.0 Best Current Practice for Native Apps

The IETF ([Internet Engineering Task Force](https://www.ietf.org/)) recently released the [Best Current Practice for OAuth 2.0 for Native Apps Request For Comments](https://www.rfc-editor.org/rfc/rfc8252.txt). This document requires that, in accordance with best practices, only external user agents (such as the browser) should be used with the [OAuth 2.0 Authorization Framework](https://tools.ietf.org/html/rfc6749) by native applications; this is known as the "AppAuth pattern". Embedded user agents should not be implemented.

> _For authorizing users in native apps, the best current practice is to perform the OAuth authorization request in an external user agent (typically the browser) rather than an embedded user agent (such as one implemented with web-views)._
>
> -_[OAuth 2.0 for Native Apps](https://www.rfc-editor.org/rfc/rfc8252.txt)_

Using the browser to make native app authorization requests results in better security. It also enables use of the user's current authentication state, making single sign-on possible. Embedded user agents are unsafe for third parties. If used, the app has access to the OAuth authorization grant as well as the user's credentials, leaving this data vulnerable to recording or malicious use. Embedded user agents also don't share authentication state, meaning no single sign-on benefits can be conferred.

We'll go into the security and implementation advantages of using the browser for authorization requests in more detail below.

<include src="TweetQuote" quoteText="Using the browser to make native app authorization requests results in better security."/>

### Authorization Flow for Native Apps Using the Browser

The authorization flow for native apps using the browser acts as illustrated in the following diagram:

![Authorization flow for OAuth 2.0 in native apps using the browser](https://images.ctfassets.net/23aumh6u8s0i/3ULKZFPLQiGXHa9NFNCpCS/bd5c463c34ae60a1aee86af0db199b3a/hoauth-flow)

> 1. Client app opens a browser tab with the authorization request.
2. Authorization endpoint receives the authorization request, authenticates the user, and obtains authorization. Authenticating the user may involve chaining to other authentication systems.
3. Authorization server issues an authorization code to the redirect URI.
4. Client receives the authorization code from the redirect URI.
5. Client app presents the authorization code at the token endpoint.
6. Token endpoint validates the authorization code and issues the tokens requested.
>
> _Figure 1, [OAuth 2.0 for Native Apps](https://www.rfc-editor.org/rfc/rfc8252.txt)_

URIs are used for OAuth 2.0 on the web for authorization requests and responses. Similarly, URIs can also be used in native apps. When the built-in browser is employed by the user for all native app logins, certain advantages are conferred, such as the ability to use a single sign-on session stored in a central location and additional security afforded by an authentication context that is separated from the app. Browser security is also a major focus of vendors, and they tend to manage security and sessions policies quite well. In addition, supporting and implementing the same approach in web and native apps reduces complexity and increases interoperability.

<include src="TweetQuote" quoteText="Implementing external user agents in both web & native apps reduces complexity and increases interop."/>

### Initiating and Receiving Authorization Requests

Native apps now must request user authorization by creating a URI with the appropriate [grant type specified in the OAuth 2.0 Authorization Framework](https://tools.ietf.org/html/rfc6749#section-4.1). The app then redirects the user to this request URI. A redirect URI that the native app can receive and parse appropriately must also be supplied. This must be implemented using an _external user agent_. Use of the device browser is recommended.

The authorization server must permit at least three redirect URI options for the response sent back to the native app:

* Private-Use URI Scheme Redirection
* Claimed "https" Scheme URI Redirection
* Loopback Interface Redirection

You can read about these three options in detail in Section 7 of [OAuth 2.0 for Native Apps](https://www.rfc-editor.org/rfc/rfc8252.txt).

## OAuth 2.0 Security Considerations for Native Apps

When implementing OAuth 2.0, there are a number of security considerations that developers must be mindful of when using best current practice with an external user agent. We'll go over a few of them now.

### Authorization Code and Grant Flow

Using the redirect options above means that the authorization code can only be received by native apps on the same device. While this increases security, it does still mean that another app on the same device could potentially intercept the code. The [Proof Key for Code Exchange (PKCE) protocol](https://tools.ietf.org/html/rfc7636) was created to defend against this attack vector. Public apps as well as servers _must_ use PKCE, and servers should reject authorization requests from apps that do not.

It is _not_ recommended to implement [implicit grant flow](https://auth0.com/docs/api-auth/grant/implicit) in native apps because this flow cannot be protected by PKCE. Instead, [authorization code grant flow with PKCE](https://auth0.com/docs/api-auth/grant/authorization-code-pkce) should be used.

### Authorization Servers and Clients

In most cases, native apps are considered public clients and must be registered with the authorization server. Authorization servers must also register a client's complete redirect URI. If an authorization request does not match the registered redirect URI, the request must be rejected.

User authentication and consent will be required by the authorization server, as per any other web browser based OAuth 2.0 flows.

### User Agents

Embedded user agents should not be used to masquerade as an external user agent. Authorization servers can protect against these fake agents by requiring an authentication factor only available to genuine external user agents.

Cross-Site Request Forgery (CSRF) attacks should also be mitigated by using the `state` parameter to link client requests and responses. More details are available in section 5.3.5 of [OAuth 2.0 Threat Model and Security Considerations](https://tools.ietf.org/html/rfc6819).

The user's browser is the recommended external user agent. Embedded user agents must not be used for authorization requests. Authorization servers may detect and block requests from embedded user agents, as they are unsafe for third parties, such as the authorization server itself. The reason for this is because the app can then access not only the OAuth authorization grant, but also the user's full authentication credentials. The app could then potentially record or use this information maliciously. In addition, embedded user agents don't share authentication state with other apps or the browser and therefore disabling single sign-on benefits.

## Conclusion

If you're a native app developer, it's very important to adhere to best current practices. Please take the time to read over the [OAuth 2.0 for Native Apps](https://www.rfc-editor.org/rfc/rfc8252.txt) RFC yourself. Using an external user agent for OAuth 2.0 authorization requests provides better security as well as an improved user experience as it enables [single sign-on](https://auth0.com/blog/what-is-and-how-does-single-sign-on-work/) across the device's apps and browser.

### Centralized Login with Auth0

[Auth0](https://auth0.com) provides a [centralized login approach](https://auth0.com/docs/hosted-pages/login) that adheres to the OAuth 2.0 Best Current Practice for native apps. Centralized login provides the most secure experience and is also easy to implement for developers. A URI is used to trigger an authentication request and the centralized login page is shown to users. This login page can use the [Auth0 Lock widget](https://auth0.com/lock) or your own custom UI. After authorization, the user is returned to your app via your provided redirect. Auth0 provides extensive documentation to help you easily implement the appropriate flows to keep your apps secure and user-friendly as well.

Check out the following resources to learn more about implementing Auth0 with centralized login in your native apps in accordance with the OAuth 2.0 Best Current Practice:

* [Centralized Login Page](https://auth0.com/docs/hosted-pages/login)
* [OAuth 2.0](https://auth0.com/docs/protocols/oauth2)
* [Calling APIs from Mobile Apps (Authorization Code PKCE)](https://auth0.com/docs/api-auth/grant/authorization-code-pkce)
* [iOS Swift Quickstart - Login](https://auth0.com/docs/quickstart/native/ios-swift/00-login)
* [Android Quickstart - Login](https://auth0.com/docs/quickstart/native/android/00-login)

You can sign up for a <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">free Auth0 account now</a> and get started right away, or check out [Auth0's pricing here](https://auth0.com/pricing).


OAuth 2.0 Best Practices for Native Apps

99c4080f412ccf46b9b564db7f482907?s=200 avatar

99c4080f412ccf46b9b564db7f482907?s=200

I'm currently a Senior Developer Advocate at MongoDB. I'm also a Google Developer Expert for Web Technologies and spend most my time giving talks at conferences and meetups, mentoring developers and running workshops, and creating online content to help technology professionals.

Former Auth0 Employee

Ado Kukic

A look at five frameworks for building cross-platform mobile applications and how they stack up against each other.



---

**TL;DR** Mobile apps are here to stay. For a long time, mobile app development required extensive Objective-C or Java knowledge. Hybrid frameworks and transpilers existed, but paled in comparison to what could be accomplished building apps natively. In recent years, these frameworks have started catching up on features, functionality and performance. Today, we'll take a look at five promising frameworks for building cross-platform mobile applications.

---

Two mobile platforms dominate the landscape; Apple's iOS and Google's Android. Combined, these two platforms make up [99%](http://www.idc.com/promo/smartphone-market-share/) of all mobile devices. Between the two platforms, over 4.2 million mobile apps have been released in categories such as gaming, education, business, music, and more.

Android is based on Java while iOS runs on Objective-C and Swift: two fundamentally different frameworks for developers to target. For a long time, companies wishing to develop mobile apps had to have two teams, one dedicated to iOS development and the other to Android. Hybrid or cross-platform frameworks and transpilers have gained popularity as they allow developers to target multiple platforms with a single code base, reducing cost and development time.

Today we will take a look at alternatives to building native mobile applications. We will look at various frameworks and approaches to bringing your app to the small screen and the pros and cons of each. Without further ado, let's jump right in.

## Ionic

![Ionic](https://images.ctfassets.net/23aumh6u8s0i/2yioqHIIiETG7TrrMhooHG/fd5221941cb9513fe7130df5bff14a71/ionic-logo)

[Ionic](https://ionicframework.com/) is perhaps the most widely known cross-platform mobile framework. It allows developers to build iOS and Android applications with web technologies such as HTML, CSS, and JavaScript. Ionic is built on top of [Cordova](https://cordova.apache.org/) which enables access to various device features such as geolocation, push notifications, camera, and others. Ionic 1.x utilizes [Angular 1.x](https://angularjs.org/), while Ionic 2, the latest version of the framework, utilizes [Angular 2+](https://angular.io/).

In addition to the framework, Ionic boasts an entire ecosystem to get developers up and running as quickly as possible. [Ionic Cloud](https://ionic.io/cloud) gives developers various tools to manage, deploy, and scale their Ionic applications. [Ionic Creator](https://ionic.io/products/creator) is a visual editor that allows developers to rapidly prototype and build mobile applications via drag and drop. Finally, [Ionic View](http://view.ionic.io/) is a free iOS and Android app that allows developers to easily share their Ionic app with users, testers, and clients without having to deploy the application to any app store. Developers simply invite users via the Ionic View app, and once an invite has been accepted the user can download and run the developers app inside of Ionic View as if the app was installed on their phone.

<include src="TweetQuote" quoteText="Ionic enables the development of mobile apps built with web technologies like HTML, CSS, and JS."/>

### Pros
* Build mobile apps with familiar web technologies such as HTML, CSS, and JavaScript.
* Ionic View allows you to share your Ionic app without requiring a user to download it.
* Target iOS and Android devices with a single code base.

### Cons
* Ionic apps use [WebView](https://developer.android.com/reference/android/webkit/WebView.html), which means the app is for all intents and purposes a web application, so performance can be slow compared to native applications.
* Ionic requires deep knowledge of Angular to get the most out of the framework.
* Not suitable for complex mobile applications such as games or graphics intensive programs.

## PhoneGap / Cordova

![PhoneGap](https://images.ctfassets.net/23aumh6u8s0i/6kuj61dIq9Cvp5eYbxofta/22c17124939107f4f4b3d162f08f2e56/phonegap-logo)

[PhoneGap](http://phonegap.com/) is very similar to Ionic in many respects. It too allows developers to build cross-platform mobile applications with web technologies and is built on top of Cordova. PhoneGap is not tied to any specific JavaScript framework, so developers have more choice in how they build their applications. PhoneGap boasts an ecosystem comprised of a desktop app, mobile app, and a cloud service called [PhoneGap Build](https://build.phonegap.com/) for building and deploying an application.

There is often confusion in the developer community regarding PhoneGap and Cordova. PhoneGap was originally founded by [Nitobi](https://www.crunchbase.com/organization/nitobi-software#/entity). In 2011, [Adobe](https://adobe.com) acquired Nitobi and the PhoneGap brand. Adobe then donated a version of PhoneGap, renamed Cordova, to the [Apache Foundation](https://www.apache.org/), but kept the PhoneGap brand and product. Cordova can be seen as the engine that powers PhoneGap, amongst other hybrid frameworks. PhoneGap adds additional features and functionality on top of Cordova.

<include src="TweetQuote" quoteText="Cordova allows you to build cross-platform mobile apps with web technologies of your choice."/>

### Pros
* Build cross-platform mobile apps with web technologies of your choice.
* PhoneGap build allows you to compile your PhoneGap apps into iOS and Android apps without having to install any additional SDKs.
* Extensive third-party plugin library offering integrations such as mobile payments, testing frameworks, and more.

### Cons
* PhoneGap, like Ionic, uses WebView which results in performance challenges.
* Lack of standard UI library.
* Not suitable for complex mobile applications such as games or graphics intensive programs.

## Xamarin

![Xamarin](https://images.ctfassets.net/23aumh6u8s0i/3oVHsVIYit1VXh5nZRDJaT/d825fd98fe16a70e435be5e9669f9328/xamarin-logo)

[Xamarin](https://www.xamarin.com/) comes from [Microsoft](https://microsoft.com) and takes a unique approach to cross-platform app development. Xamarin applications are written entirely in C#. Xamarin then compiles the C# code into native iOS and Android distributions. The underlying layer on which Xamarin is built on top of is [Mono](http://www.mono-project.com/) and this enables cross-platform development. The benefit of building applications with Xamarin compared to Cordova-based frameworks is that apps built with Xamarin make use each platform's native API's. This means that Xamarin apps compile down to native iOS and Android applications and behave as such.

Xamarin is not a code once, run everywhere solution. While you can achieve a high level of code shareability, you will more than likely need to write specific code for iOS and Android versions of your app. With Xamarin, you will not be able to use native open-source libraries that are available for iOS and Android, but you can make use of many .Net libraries. Finally, getting access to the latest native APIs can be slow since the Xamarin developers will have to implement them into the framework after they are released.

<include src="TweetQuote" quoteText="Xamarin allows you to build cross-platform iOS and Android applications in C-Sharp."/>

### Pros
* Developers already familiar with the Microsoft ecosystem will feel right at home with Xamarin and its use of C#.
* Xamarin apps have access to all of the native capabilities of both iOS and Android.
* Performance of Xamarin apps is comparable to that of natively written applications.

### Cons
* Although you can achieve code shareability, you will occasionally need to write platform specific code.
* You will need to understand iOS and Android APIs to be able to get the most of out the platform.
* The licensing model can be difficult to navigate with certain features locked behind Professional and Enterprise licenses.

## React Native

![React Native](https://images.ctfassets.net/23aumh6u8s0i/2tTNuAm4EON8PmLhdweSSD/e2b2a1c49194dd7da2b82364b121a95d/react-native-logo)

[React Native](https://facebook.github.io/react-native/) comes to us from [Facebook](https://facebook.com) and presents a framework for building cross-platform mobile applications with [React](https://facebook.github.io/react/). React Native is comparable to Xamarin, wherein apps created with React Native are indistinguishable from native iOS and Android apps written in Objective-C or Java.

React Native combines the easy to learn syntax of React but also enables developers to write Objective-C, Swift, or Java when needed for additional performance or tuning. This means that developers can use existing native libraries in their React Native apps. React Native also comes with many UI components such as buttons, sliders, and modals that allow developers to get up and running quickly.

<include src="TweetQuote" quoteText="React allows developers to build native iOS and Android apps with React and JavaScript."/>

### Pros
* Since React Native apps run native APIs, the performance is comparable to true native apps.
* You can use native libraries and write Objective-C, Swift, or Java if needed to further optimize performance.
* The standard UI component library is extensive and provides many features out-of-the-box.

### Cons  
* Requires extensive knowledge of React.
* Depending on use case, you may end up writing a lot of native code and then plugging it into React Native, which means you'll need Objective-C or Java knowledge.
* While React and React Native are open source projects, Facebook has faced criticism of its BSD+Patents licensing model.

## Progressive Web Apps

![Progressive Web Apps](https://images.ctfassets.net/23aumh6u8s0i/7HjmYoyE9g9l8euwDFgR61/550512b9bc7abb75115f67d1fb012f75/pwa-intro)

[Progressive Web Apps](https://developers.google.com/web/progressive-web-apps/) aim to make web applications behave like their native counterparts. This project comes to us from [Google](https://google.com) and presents a very interesting proposition. Progressive Web Apps aim to be reliable, fast, and engaging. This means that apps should load fast, present an engaging and fluid user experience, and support native features like push notifications or offline access. The PWA spec will add new features and functionality over time. Developers can then choose how many features they wish to implement, possibly making PWA the most flexible way to reach mobile users.

Progressive Web Apps are unique for two major reasons. While they can be "installed" on a user's homescreen, they are not delivered through the App Store or Google Play. Instead, when a user visits a PWA, they are presented with an option to add it to their homescreen. This is interesting because it gives the developer the power to deliver and update their applications without forcing the user to do anything. In addition, Progressive Web Apps can be scraped and indexed by search engines. This significantly increases discoverability and opens doors for deeper integrations in the future.

<include src="TweetQuote" quoteText="Progressive Web Apps allow developers to add mobile features to existing web applications."/>

### Pros
* No need for separate code base. Your web application is your mobile application.
* App will be indexed and discoverable through search engines.
* App does not need to go through the App Store or Google Play to be "installed" on a user's mobile device.

### Cons
* Limited support for PWA on iOS.
* Lack of access to many native APIs.
* App won't be accessible through App Store or Google Play.

## Authentication with Hybrid App Frameworks

Mobile applications present various user and identity challenges. Luckily, [Auth0](https://auth0.com) has your back. Our [identity solution is platform agnostic](https://auth0.com/user-management) and we have plenty of resources to get you up and running as quickly as possible. <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">Sign up</a> for a free Auth0 account, and then follow any of these guides to get user authentication for your app in no time at all:

* **Ionic** - [Quickstart (Ionic)](https://auth0.com/docs/quickstart/native/ionic), [Quickstart (Ionic 2)](https://auth0.com/docs/quickstart/native/ionic2), [Tutorial](https://auth0.com/blog/ionic-2-authentication-how-to-secure-your-mobile-app-with-jwt/)
* **PhoneGap** - [Quickstart](https://auth0.com/docs/quickstart/native/phonegap)
* **Xamarin** - [Quickstart](https://auth0.com/docs/quickstart/native/xamarin), [Tutorial](https://auth0.com/blog/xamarin-authentication-and-cross-platform-app-development/)
* **React Native** - [Quickstart (iOS)](https://auth0.com/docs/quickstart/native/react-native-ios), [Quickstart (Android)](https://auth0.com/docs/quickstart/native/react-native-android)
* **Progressive Web Apps** - [Tutorial](https://auth0.com/blog/introduction-to-progressive-apps-part-one/)

> [Auth0 offers a generous **free tier**](https://auth0.com/pricing) so we can get started with modern authentication.

## Conclusion

Mobile application development is more accessible than ever. Whether you are a full-stack developer, aspiring engineer, or have decades of experience in the Microsoft ecosystem, you can build great mobile applications that can run on billions of devices today. There may not be clear a winner, each platform has pros and cons, but the important thing is you have a plethora of options. As the old adage goes, "use the right tool for the job". Hopefully you've learned more about native app alternatives and can make an informed decision about developing mobile applications.


Alternatives to Native Mobile App Development

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.

Prosper Otemuyiwa

Progressive Web Apps are the future. Learn how to make your mobile web app native-like by making it work offline, load instantly and send push notifications.

Introduction to Progressive Web Apps (Push Notifications) - Part 3

Progressive Web Apps are the future. Learn how to make your mobile web app native-like by making it work offline and load instantly.



---

**TL;DR:** Web development has evolved significantly over the years allowing developers to deploy a website or web application and serve millions of people around the globe within minutes. With just a browser, a user can put in a URL and access a web application. With, **Progressive Web Apps**, developers can deliver amazing app-like experiences to users using modern web technologies. In the [first part of this tutorial](https://auth0.com/blog/introduction-to-progressive-apps-part-one) we set up our progressive web app, cached the pages and made it work partially offline. This time, we'll make it load instantly and work offline fully.

---

## Recap and Introduction to Part 2

In [Introduction to Progressive Web Apps (Offline First)](https://auth0.com/blog/introduction-to-progressive-apps-part-one), we discussed how a typical progressive web application should look like and also introduced the service worker. So far, we've cached the application shell. The `index` and `latest` pages of our web app now load offline. They also load faster on repeated visits. Towards the end of the first part of this tutorial, we were able to load the `latest` page offline but couldn't get dynamic data to display when the user is offline.

This tutorial will cover:

* Caching the App data on the `latest` page to be displayed to the user when offline
* Using `localStorage` to store the App data
* Flushing out old App data and fetching updated data when the user is connected to the internet


## Offline Storage

When building progressive web apps, there are various storage mechanisms to consider like so:

* **[IndexedDB](https://developer.mozilla.org/en/docs/Web/API/IndexedDB_API):** This is a transactional JavaScript based database system for client-side storage of data. This database employs the use of indexes to enable high performance searches of the data stored in it. IndexedDB exposes an asynchronous API that supposedly avoids blocking the DOM, but some research has shown that in some cases it is blocking. I recommend that you use libraries when working with IndexedDB because manipulating it in vanilla JavaScript can be very verbose and complex. Examples of good libraries are [localForage](https://mozilla.github.io/localForage), [idb](https://www.npmjs.com/package/idb) and [idb-keyval](https://www.npmjs.com/package/idb-keyval).

  ![IndexedDB Browser Support](https://images.ctfassets.net/23aumh6u8s0i/3TAkSh1K0jquHYGmAIKlG0/177eb267243366d60a232f9b3b3e99c3/indexeddbsupport)

  _IndexedDB browser support_
* **[Cache API](https://developer.mozilla.org/en-US/docs/Web/API/Cache):** This is best for storing url addressable resources. Works with Service worker really well.
* **[PouchDB](https://pouchdb.com):** Open Source JavaScript database inspired by [CouchDB](http://couchdb.apache.org). It enables applications to store data locally while offline, then synchronize it with CouchDB and compatible servers when the application is back online, keeping the user's data in sync no matter where they next login. PouchDB supports all modern browsers, using IndexedDB under the hood and falling back to WebSQL where IndexedDB isn't supported. Supported in *Firefox 29+ (Including Firefox OS and Firefox for Android), Chrome 30+, Safari 5+, Internet Explorer 10+, Opera 21+, Android 4.0+, iOS 7.1+* and *Windows Phone 8+*.
* **[Web Storage e.g localStorage](https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API):** It is synchronous and can block the DOM. The usage is capped at 5MB in most browsers. It has a simple API for storing data and it uses key-value pairs. 
  
  ![Web Storage Browser Support](https://images.ctfassets.net/23aumh6u8s0i/5t6F5vI9NFvk8MiYbFg0rs/c2804c91dc9d0c15279788ebcf9ec1c0/webstorage)

  _Web Storage browser support_

* **[WebSQL](https://www.w3.org/TR/webdatabase):** This is a relational database solution for browsers. It has been deprecated and the [specification](https://www.w3.org/TR/webdatabase) is no longer maintained. So, browsers may not support it in the future.

![Quota for Mobile Storage](https://images.ctfassets.net/23aumh6u8s0i/nDs06JOzFjU8L5N741a75/593af684f2f1ff25b050093afccf15dc/mobile)

_Mobile Storage Quota_

[Addy Osmani](https://twitter.com/addyosmani) has a comprehensive resource on [Offline storage for progressive web apps](https://medium.com/dev-channel/offline-storage-for-progressive-web-apps-70d52695513c#.j7e7w3m7g). You should really check it out!

According to PouchDB maintainer, [Nolan Lawson](https://twitter.com/nolanlawson), do well to ask yourself these questions when you are using a database:

* Is this database in-memory or on-disk(PouchDB, IndexedDB)?
* What needs to be stored on disk? What data should survive the application being closed or crashing?
* What needs to be indexed in order to perform fast queries? Can I use an in-memory index instead of going to disk?
* How should I structure my in-memory data relative to my database data? What’s my strategy for mapping between the two?
* What are the query needs of my app? Does a summary view really need to fetch the full data, or can it just fetch the little bit it needs? Can I lazy-load anything?

You can check out [how to think about databases](https://nolanlawson.com/2016/02/08/how-to-think-about-databases) to give you a broader knowledge on the subject matter.


## Let's Implement Instant Loading

For our web app, we'll use `localStorage` . I recommend that you don't use `localStorage` for production apps because of the limitations I highlighted earlier in this tutorial. The app we are building is a very simple one, so `localStorage` will work fine.

Open up your `js/latest.js` file. We will update the `fetchCommits` function to store the data it fetches from the Github API in `localStorage` like so:

```js


 function fetchCommits() {
    var url = 'https://api.github.com/repos/unicodeveloper/resources-i-like/commits';

    fetch(url)
    .then(function(fetchResponse){ 
      return fetchResponse.json();
    })
    .then(function(response) {
        console.log("Response from Github", response);

        var commitData = {};

        for (var i = 0; i < posData.length; i++) {
          commitData[posData[i]] = {
            message: response[i].commit.message,
            author: response[i].commit.author.name,
            time: response[i].commit.author.date,
            link: response[i].html_url
          };
        }

        localStorage.setItem('commitData', JSON.stringify(commitData));

        for (var i = 0; i < commitContainer.length; i++) {

          container.querySelector("" + commitContainer[i]).innerHTML = 
          "<h4> Message: " + response[i].commit.message + "</h4>" +
          "<h4> Author: " + response[i].commit.author.name + "</h4>" +
          "<h4> Time committed: " + (new Date(response[i].commit.author.date)).toUTCString() +  "</h4>" +
          "<h4>" + "<a href='" + response[i].html_url + "'>Click me to see more!</a>"  + "</h4>";

        }

        app.spinner.setAttribute('hidden', true); // hide spinner
    })
    .catch(function (error) {
      console.error(error);
    });
};

```

With this piece of code above, on first page load, the commit data will be stored in `localStorage`. Now let's write another function to retrieve the data from `localStorage` like so:

```js

  // Get the commits Data from the Web Storage
  function fetchCommitsFromLocalStorage(data) {
    var localData = JSON.parse(data);

    app.spinner.setAttribute('hidden', true); //hide spinner

    for (var i = 0; i < commitContainer.length; i++) {

      container.querySelector("" + commitContainer[i]).innerHTML = 
      "<h4> Message: " + localData[posData[i]].message + "</h4>" +
      "<h4> Author: " + localData[posData[i]].author + "</h4>" +
      "<h4> Time committed: " + (new Date(localData[posData[i]].time)).toUTCString() +  "</h4>" +
      "<h4>" + "<a href='" + localData[posData[i]].link + "'>Click me to see more!</a>"  + "</h4>";

    }
  };

```

This piece of code fetches data from `localStorage` and appends it to the DOM. 

Now, we need a conditional to know when to call the `fetchCommits` and `fetchCommitsFromLocalStorage` function. 

The updated `latest.js` file should look like so:

_latest.js_

```js

(function() {
  'use strict';

  var app = {
    spinner: document.querySelector('.loader')
  };

  var container = document.querySelector('.container');
  var commitContainer = ['.first', '.second', '.third', '.fourth', '.fifth'];
  var posData = ['first', 'second', 'third', 'fourth', 'fifth'];

  // Check that localStorage is both supported and available
  function storageAvailable(type) {
    try {
      var storage = window[type],
        x = '__storage_test__';
      storage.setItem(x, x);
      storage.removeItem(x);
      return true;
    }
    catch(e) {
      return false;
    }
  }

  // Get Commit Data from Github API
  function fetchCommits() {
    var url = 'https://api.github.com/repos/unicodeveloper/resources-i-like/commits';

    fetch(url)
    .then(function(fetchResponse){ 
      return fetchResponse.json();
    })
    .then(function(response) {
        console.log("Response from Github", response);

        var commitData = {};

        for (var i = 0; i < posData.length; i++) {
          commitData[posData[i]] = {
            message: response[i].commit.message,
            author: response[i].commit.author.name,
            time: response[i].commit.author.date,
            link: response[i].html_url
          };
        }

        localStorage.setItem('commitData', JSON.stringify(commitData));

        for (var i = 0; i < commitContainer.length; i++) {

          container.querySelector("" + commitContainer[i]).innerHTML = 
          "<h4> Message: " + response[i].commit.message + "</h4>" +
          "<h4> Author: " + response[i].commit.author.name + "</h4>" +
          "<h4> Time committed: " + (new Date(response[i].commit.author.date)).toUTCString() +  "</h4>" +
          "<h4>" + "<a href='" + response[i].html_url + "'>Click me to see more!</a>"  + "</h4>";

        }

        app.spinner.setAttribute('hidden', true); // hide spinner
      })
      .catch(function (error) {
        console.error(error);
      });
  };

  // Get the commits Data from the Web Storage
  function fetchCommitsFromLocalStorage(data) {
    var localData = JSON.parse(data);

    app.spinner.setAttribute('hidden', true); //hide spinner

    for (var i = 0; i < commitContainer.length; i++) {

      container.querySelector("" + commitContainer[i]).innerHTML = 
      "<h4> Message: " + localData[posData[i]].message + "</h4>" +
      "<h4> Author: " + localData[posData[i]].author + "</h4>" +
      "<h4> Time committed: " + (new Date(localData[posData[i]].time)).toUTCString() +  "</h4>" +
      "<h4>" + "<a href='" + localData[posData[i]].link + "'>Click me to see more!</a>"  + "</h4>";

    }
  };

  if (storageAvailable('localStorage')) {
    if (localStorage.getItem('commitData') === null) {
      /* The user is using the app for the first time, or the user has not
       * saved any commit data, so show the user some fake data.
       */
      fetchCommits();
      console.log("Fetch from API");
    } else {
      fetchCommitsFromLocalStorage(localStorage.getItem('commitData'));
      console.log("Fetch from Local Storage");
    }   
  }
  else {
    toast("We can't cache your app data yet..");
  }
})();

```

In the piece of code above, we are checking if the browser supports `localStorage` and if it does, we go ahead to check if the commit data has been cached. If it has not been cached, we fetch, display and cache the app's commit data.

Now, reload the browser again, make sure you do a hard, clear-cache, reload else we won't see the result of our code changes. 

Now, go offline and load the `latest` page. What happens?

Yaaay!! it loads the data without any problem.

![Load Dynamic Data Offline](https://images.ctfassets.net/23aumh6u8s0i/36OIqp3X2ZgkuGhLrElTuo/59cb767fae6efe1286ae47c0311f0358/pwacommits)

Check the **DevTools**, you'll see the data been stored in `localStorage`.

![Store Data Locally](https://images.ctfassets.net/23aumh6u8s0i/7BqkhLztkyPWUy4r9kPNNG/ed3e4bfebb1a77f4cc3a518916aa4607/data-stored-locally)
_Store Data Locally_

Just look at the speed at which it loads when the user is offline....OMG!!!

![Loads From Service Worker](https://images.ctfassets.net/23aumh6u8s0i/3i5tSnwsD9hz4TSLCJhyCR/badb2a218fa38c57a507cb4c13a3eb63/load_from_service_worker)
_Loads from Service Worker when user is offline_

## One More Thing

Now, we can make the app load instantly by fetching data from the localStorage. How do we get fresh updated data? We need a way of still getting fresh data especially when the user is online.

It's simple. Let's add a refresh button that triggers a request to GitHub to get the most recent data.

Open up your `latest.html` file and add this code for the refresh button within the `<header>` tag.

```html

<button id="butRefresh" class="headerButton" aria-label="Refresh"></button>

```

So the `<header>` tag should look like this after adding the button:

```html

<header>
  <span class="header__icon">
    <svg class="menu__icon no--select" width="24px" height="24px" viewBox="0 0 48 48" fill="#fff">
      <path d="M6 36h36v-4H6v4zm0-10h36v-4H6v4zm0-14v4h36v-4H6z"></path>
    </svg>
  </span>
  <span class="header__title no--select">PWA - Commits</span>
  <button id="butRefresh" class="headerButton" aria-label="Refresh"></button>
</header> 

```

Finally, let's attach a `click` event to the button and add functionality to it. Open your `latest.js` and add this code at the top like so:

```js

document.getElementById('butRefresh').addEventListener('click', function() {
    // Get fresh, updated data from GitHub whenever you are clicked
    toast('Fetching latest data...');
    fetchCommits();
    console.log("Getting fresh data!!!");
});

```

Clear your cache and reload the app. Now, your `latest.html` page should look like so:

![PWA - Get Updated data](https://images.ctfassets.net/23aumh6u8s0i/MhrrMYrgjMApmPLbCbBdh/11496d354460a2d24895c74e73397b4c/latest_data)

_Get Updated data_

Anytime users need the most recent data, they can just click on the refresh button.


## Aside: Easy Authentication with Auth0

You can use [Auth0 Lock](https://auth0.com/docs/libraries/lock) for your progressive web app. With Lock, showing a login screen is as simple as including the **auth0-lock** library and then calling it in your app like so:

```js

// Initiating our Auth0Lock
var lock = new Auth0Lock(
  'YOUR_CLIENT_ID',
  'YOUR_AUTH0_DOMAIN'
);

// Listening for the authenticated event
lock.on("authenticated", function(authResult) {
  // Use the token in authResult to getProfile() and save it to localStorage
  lock.getProfile(authResult.idToken, function(error, profile) {
    if (error) {
      // Handle error
      return;
    }

    localStorage.setItem('idToken', authResult.idToken);
    localStorage.setItem('profile', JSON.stringify(profile));
  });
});

```

**Note:** If you want to use Auth0 authentication to authorize _API requests_, note that you'll need to use [a different flow depending on your use case](https://auth0.com/docs/api-auth/which-oauth-flow-to-use). Auth0 `idToken` should only be used on the client-side. [Access tokens should be used to authorize APIs](https://auth0.com/blog/why-should-use-accesstokens-to-secure-an-api/). You can read more about [making API calls with Auth0 here](https://auth0.com/docs/apis).

_Implementing Lock_

```js

document.getElementById('btn-login').addEventListener('click', function() {
  lock.show();
});

```

_Showing Lock_


![Auth0 Lock Screen](https://images.ctfassets.net/23aumh6u8s0i/ElPRQ0cfHgykYZStjyH3D/709b6df945b846607fee305380d134f5/nexthrone-auth0lock)

_Auth0 Lock Screen_

In the case of an offline-first app, authenticating the user against a remote database won't be possible when network connectivity is lost. However, with service workers, you have full control over which pages and scripts are loaded when the user is offline. This means you can configure your `offline.html` file to display a useful message stating the user needs to regain connectivity to login again instead of displaying the Lock login screen.

## Conclusion

In this article, we were able to make our app load instantly and work offline. We were able to cache our dynamic data and serve the user the cached data when offline. 

In the final part of this tutorial, we will cover how to enable push notifications, add web application manifest and our app to a user's homescreen.


Introduction to Progressive Web Apps (Instant Loading) - Part 2

Progressive Web Apps are the future. Implement offline functionality and make your mobile web app feel like a native app.

Introduction to Progressive Web Apps (Offline First) - Part 1

The NGINX Plus R10 release comes with native support for the JWT authentication standard. Learn how this can change the way your app handles authentication.



---

**TL;DR** NGINX Plus R10 brings native [JSON Web Token (JWT)](https://jwt.io/introduction/) support to the popular server. This enhanced capability allows NGINX Plus to validate JWTs and reject requests that do not have valid JWTs associated with them. This is very useful in protecting API clients and in this post we'll take a look at how we can leverage this new feature in our applications. 

---

[NGINX Plus R10](https://www.nginx.com/blog/nginx-plus-r10-released/) has only been out for a few weeks but it's got us very excited. The latest release boasts many new features and improvements including: "Dual-stack" support for ECC and RSA Certificates, transparent proxy support, nginScript support, and more. The feature we are most excited about is native support for **JSON Web Tokens (JWT)**.

With the R10 release, NGINX Plus makes it easy to protect your APIs and services with JWTs. In this post, we'll look at why you would want to offload the authorization aspect of your app to NGINX and then we'll build an application that does exactly this. We'll use Auth0 to issue the JWTs for us, but the same workflow is applicable to any JWT issuer.

## NGINX Plus JWT Support

Many companies employ NGINX as a reverse proxy or load balancer for their applications. This means that NGINX sits between the users making requests and your actual application servers. NGINX is the first point of contact between a request and your API or service. From here, the request is routed to the correct server for further processing and finally a response is served. If your API requires a user to be authenticated to access a resource, the validation of the request is typically performed after the request has passed through NGINX.

If the user requesting a protected resource is not authenticated, they've just wasted CPU cycles on both your NGINX server, bandwidth between NGINX and your application server, and resources on your application server, all so you could tell them they need to login.

The NGINX Plus `auth_jwt` directive verifies that the user is authenticated and has permissions to access a resource before the request is routed to your application server. If the request coming in does not have a valid JWT, the request is short-circuited and NGINX replies with an appropriate `401 Unauthorized` response. No additional resources wasted.

In addition to not wasting resources, having NGINX Plus handle JWT verification allows developers to focus on implementing business logic instead of building authentication systems. Since NGINX Plus can pass the authenticated user claims directly to the application server, performance gains could also be argued as the app server has less to do. The overhead of adding JWT verification to NGINX is also trivial, as NGINX is rarely the bottleneck in the infrastructure.

<include src="TweetQuote" quoteText="NGINX Plus native JWT support means developers can offload JWT verification and focus on business logic"/>

## Configuring NGINX Plus with JWT Support

With the benefits of having NGINX Plus handle JWT verification for us clear as day, let's see how we can get this implemented. 

*Since NGINX Plus is only available on Linux distributions, we'll be using an Ubuntu virtual machine for our demo.*

### Building our Application Server

For starters, let's create a mock API server. I'll just create a quick server with Node.js and Express and expose a couple of different routes. Take a look at the implementation of our application server below:

```js
// Declare dependencies
var express = require('express');
var app = express();

// Add some public routes that are accessible to everyone
app.get('/', function(req, res){
	res.send('<h1>Welcome to the Hompeage. <small>(Everyone can view this page)</small></h1>');
})

app.get('/about', function(req, res){
	res.send('<h1>Welcome to the about page<small>(Everyone can view this page)</small></h1>');
})

// Add some protected routes that only authenticated users will have access to
app.get('/api/leads', function(req, res){
	res.json({leads:[{id: 12345, name: 'ACME Corp'}, {id: 23456, name:'LeadGen'}, {id:45677, name: 'Organic Leads'}]})
})

app.get('/api/employees', function(req, res){
	res.json({employees:[{name: 'Ado Kukic', username:'@ado'}, {name: 'Diego Poza', username:'@tony'}, {name:'Prosper Otemuyiwa', username:'@unicodedeveloper'}, {name:'Sebastian Peyrott', username:'@speyrott'}, {name:'Kim Maida', username:'@kim.maida'}]})
})

app.listen(9000);
```

Our server exposes four routes. Two public, two protected. Without NGINX Plus to protect our API routes, we'd have to add a couple more dependencies, add some middleware to check and verify that the incoming request had a valid JWT, implement logic for when the token is not valid and more. Luckily, we are using NGINX Plus, so we don't have to do a single other thing. We can simply deploy this server by running `node server.js` and accessing our application at `localhost:9000`.

### Configuring NGINX Plus

NGINX Plus is a premium product. It requires an annual fee, but you can also try it for free [here](https://www.nginx.com/products/). You can find the installation instructions on the official NGINX Plus [website](https://www.nginx.com/resources/admin-guide/installing-nginx-plus/). I'll assume that you already have NGINX Plus installed on your machine. If you have an older version of NGINX Plus installed, you can easily upgrade to the latest R10 release by running:

```bash
// Debian or Ubuntu
sudo apt-get update
sudo apt-get install nginx-plus

// RHEL, CentOS, or Amazon Linux
sudo yum upgrade nginx-plus

// FreeBSD
sudo pkg upgrade nginx-plus
```

Before continuing, check that the version of NGINX Plus installed on your machine is `nginx-plus-r10` or higher. With the appropriate version installed, let's configure our NGINX Plus server. Open the `nginx.conf` file and paste the following:

```
user nginx;
worker_process auto;

events {}

http {
  # Here we are defining the server that we'll pass the requests to
  upstream api_server {
    server 127.0.0.1:9000;
  }
  server {
    # Our NGINX Plus server will listen on Port 80
    listen 80;

    # By default all routes will proxy to our Node.js server at localhost:9000
    location / {
      proxy_pass http://api_server;
    }

    # For any of the /api/* routes, we'll ensure that the user has a valid JWT
    location /api/ {
      # We'll name our domain or realm our Auth0 Domain
      # This is not required so you can name it anything
      auth_jwt "YOUR-AUTH0-DOMAIN.auth0.com";
      # We'll need to load a JWK that contains our secret credentials that will be used to verify incoming JWT's
      auth_jwt_key_file /etc/nginx/secret.json;

      # If an incoming JWT is valid, we'll proxy to our Node.js server
      proxy_pass http://api_server;
    }
  }
}
```

We'll need to create a `secret.json` file next. You can create this file anywhere, as long as it's accessible by NGINX, so we'll just create it our nginx directory.

The `secret.json` file will contain a [JSON Web Key (JWK)](https://tools.ietf.org/html/rfc7517) which will hold our signing key. This file can either be a `.json` file or a `.jwk` file, as long as the format is correct. Learn more about what compromises a JWK [here](https://tools.ietf.org/html/rfc7517).

For our implementation, our JWK will look like:

```json
{"keys":
    [{
        "k":"YOUR-AUTH0-SECRET",
        "kty":"oct"
    }]
}
```

Let's go ahead and get our Auth0 client credentials so we can test our implementation. If you don't already have an Auth0 account, sign up for a free one <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">here</a>. Log in to your [management dashboard](https://manage.auth0.com), navigate to the client you wish you to use, and retreive your **Domain** and **Client Secret**. Replace the `YOUR-AUTH0-DOMAIN` from the `nginx.conf` file and with your domain and `YOUR-AUTH0-SECRET` with your secret and save the files.

![Auth0 Management Dashboard](https://images.ctfassets.net/23aumh6u8s0i/5VmGAcLFkxC2f9WMGuptQK/442660c778bf0f59c828881ec6a814f6/management-dashboard)

To start your NGINX server, run the `sudo nginx` command.

Navigate to `localhost`. You'll see the response from the Node.js server we created earlier and the text displayed: "Welcome to the Homepage". Our proxy server works. NGINX took the request from `localhost:80` and forwarded to our Node.js server at `localhost:9000`.

![Our Node.js Application](https://images.ctfassets.net/23aumh6u8s0i/7MJRdejJyEJPWTZLRXtvN5/e39694d35cfd7777e1b01796680c9f3d/our-app)

Now, let's try to access an API route, navigate to `localhost/api/leads`. You will see a `401 Unauthorized` message served from NGINX. We didn't write this page or have an implementation for it in our Node.js server. When NGINX received the request, it looked for a JWT and since we didn't pass one in, the request was rejected.

![Unauthorized NGINX Plus request](https://images.ctfassets.net/23aumh6u8s0i/4n8PaH6Oy7WEOpGVG57c21/71506bd4ed1455ffaf7f1c0c5857788d/unauthorized)

Let's send a request with a valid JWT. The easiest way to get a valid JWT for our Auth0 implementation is to visit the [Auth0 playground](https://auth0.github.io/playground/). Here, all you need to do is add your ClientID and Domain and you will be able to login with the Lock widget. Let's `console.log` the token we get upon a succesful login and copy it. For reference, our Auth0 playground code will be:

```
var domain = 'YOUR-AUTH0-DOMAIN.auth0.com';
var clientID = 'YOUR-AUTH0-CLIENTID';

var lock = new Auth0Lock(clientID, domain);
lock.show({
  focusInput: false,
  popup: true,
   authParams: {
    state: 'foo'
  }
}, function (err, profile, access_token, state, token) {
  // Console.log the access_token or JWT
  console.log(access_token)
});
```

![Auth0 Playground](https://images.ctfassets.net/23aumh6u8s0i/3Ph31s2T4ZbhFY0zBmUIi6/0bb7812e2001fee4a576229d02ae0796/auth0-playground)

Now that we have a valid JWT, let's make another request to our NGINX server, this time passing the JWT alongside the request. To accomplish this, we'll use `curl`, but you can use a GUI app like Postman to do this as well. Our command to the server will be as follows:

```bash
curl http://localhost/api/leads -H "Authorization: Bearer {JWT}"
```

The `-H` flag will append a header which we'll define as the Authorization header. The Authorization header value requires the word `Bearer` followed by a space and then the JWT. Let's run this command by hitting the return or enter key and our response will be the list of leads we defined in our Node.js server.

![Curl with valid JWT](https://images.ctfassets.net/23aumh6u8s0i/4gXuDaHbOJSPttXXdOsnpk/a4dd45a4158860a593504a76e49f9170/curl-with-jwt)

To double check and make sure that this works, try making a request without passing the Authorization header. Try running `curl http://localhost/api/leads` and you'll see the `401 Unauthorized` response.

![Curl without valid JWT](https://images.ctfassets.net/23aumh6u8s0i/11qW4xkFruCigZolxL1bhB/74cab3f377e412ce245a024bfe2f63b8/curl-without-jwt)

By default NGINX Plus looks for the Authorization header with the JWT, but we can easily change this so we can send the token as a query parameter or even a cookie. For directions on how to do that, check out [this post](https://www.nginx.com/blog/authenticating-api-clients-jwt-nginx-plus/) on the NGINX Plus blog.

*Note: Notice that on your local machine, you can go to `localhost:9000/api/leads` and see the response. This is intended as we are not validating JWTs on our Node.js server. In a real world scenario, you would not allow direct access to `localhost:9000` outside of your private network.*

## Conclusion

Today, we looked at how NGINX Plus can take the burden of validating JWTs off our application servers. We showed how you can integrate Auth0's identity platform to handle the issuance of JWTs. Since we adhere to standards, everything we covered today is also applicable to non-Auth0 JWT implementations, but for the quickest and most secure option, give us a <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">try</a>. 


Use NGINX Plus and Auth0 to Authenticate API Clients

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

Learn how to build a Native Desktop C# app and easily get up and running with JWT authentication.

Adding Authentication to a Native Desktop C# App with JWTs

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

Build a simple image calculator app with Angular 2 and Electron

<div class="alert alert-danger alert-icon">
  <i class="icon-budicon-500"></i>
  <strong>This post is out of date.</strong> Angular and Electron have undergone many changes since the publication of this article, and the method of authentication utilized in this post is not up-to-date with current best practices. We are currently working to bring you an updated tutorial on this topic!
</div>

---
**TL;DR:** Electron is an open-source project from GitHub that lets us create cross-platform desktop applications with web technologies. It doesn't matter which specific framework we use; if it works for the web, it works for Electron. We can use Angular 2 for Electron apps, and in this tutorial, we explore how to get a desktop image size calculator app wired up. Check out the [code on GitHub](https://github.com/auth0/angular2-electron).

You can also check out our other Angular 2 material, including tutorials on working with **[pipes](https://auth0.com/blog/2015/09/03/angular2-series-working-with-pipes/)**, **[models](https://auth0.com/blog/2015/09/17/angular-2-series-part-2-domain-models-and-dependency-injection/)**, and **[Http](https://auth0.com/blog/2015/10/15/angular-2-series-part-3-using-http/)**.

---

Developing desktop applications is arguably harder than developing for the web. Throw in the fact that you would need three versions of the same desktop app to make it available for all the popular operating systems, plus all the work that needs to go into preparing for distribution, and it can be a daunting task for web developers to port their skills to native. This is where Electron comes in.

[Electron](http://electron.atom.io/) is an open-source project from GitHub that makes it easy to build cross-platform desktop apps using web technologies. With it, we get a nice set of APIs for interacting with Windows, OS X, and Linux operating systems, and all we need is JavaScript. There are, of course, other ways to create desktop applications with web technologies, but Electron is unique in its ability to easily target three operating systems at once. The other nice part of building apps with Electron is that we're not barred from using any particular framework. As long as it works on the web, it works for Electron.

In this article, we'll explore how to wire up a simple image size calculator app using Electron and Angular 2. While the steps here are specific to Angular 2, remember that any front end framework will work with Electron, so these instructions could be adapted to make use of others.

![image-size-calculator app angular2 electron](https://images.ctfassets.net/23aumh6u8s0i/2fBM1k5s9xBpjOreXjDQOI/448998a3ffed9dcb695e41f15324ab25/angular2-electron-5)

## Setting Up Angular 2 and Electron

We'll use [Webpack](https://webpack.github.io/) for our Angular 2 setup, and we'll base the config loosely on the awesome [Angular 2 Webpack Starter](https://github.com/AngularClass/angular2-webpack-starter) by [AngularClass](https://angularclass.com/).

Let's start with our `package.json` file to list our dependencies, along with some `scripts` that will let us easily run our `webpack` commands and also run the `electron` command to start the app.

```js
// package.json
...

  "scripts": {
    "build": "webpack --progress --profile --colors --display-error-details --display-cached",
    "watch": "webpack --watch --progress --profile --colors --display-error-details --display-cached",
    "electron": "electron app"
  },
  "devDependencies": {
    "electron-prebuilt": "^0.35.4",
    "es6-shim": "^0.34.0",
    "ts-loader": "^0.7.2",
    "typescript": "^1.7.3",
    "webpack": "^1.12.9",
    "webpack-dev-server": "^1.14.0"
  },
  "dependencies": {
    "angular2": "2.0.0-beta.0",
    "zone.js": "^0.5.10",
    "bootstrap": "^3.3.6",
    "gulp": "^3.9.0",
    "es6-shim": "^0.33.3",
    "reflect-metadata": "0.1.2",
    "rxjs": "5.0.0-beta.0"
  }
}

...
```

Next, we need some configuration for Webpack.

```js
// webpack.config.js

var path = require('path');
var webpack = require('webpack');
var CommonsChunkPlugin = webpack.optimize.CommonsChunkPlugin;

module.exports = {
  devtool: 'source-map',
  debug: true,

  entry: {
    'angular2': [
      'rxjs',
      'reflect-metadata',
      'angular2/core',
      'angular2/router',
      'angular2/http'
    ],
    'app': './app/app'
  },

  output: {
    path: __dirname + '/build/',
    publicPath: 'build/',
    filename: '[name].js',
    sourceMapFilename: '[name].js.map',
    chunkFilename: '[id].chunk.js'
  },

  resolve: {
    extensions: ['','.ts','.js','.json', '.css', '.html']
  },

  module: {
    loaders: [
      {
        test: /\.ts$/,
        loader: 'ts',
        exclude: [ /node_modules/ ]
      }
    ]
  },

  plugins: [
    new CommonsChunkPlugin({ name: 'angular2', filename: 'angular2.js', minChunks: Infinity }),
    new CommonsChunkPlugin({ name: 'common',   filename: 'common.js' })
  ]
};
```

We're telling Webpack to bundle up the Angular 2 scripts and serve them from a single `angular2.js` bundle that will be in the `build` directory. The scripts for our app will be served from a separate bundle called `app.js`.

We also need some TypeScript configuration in a `tsconfig.json` file at the project root.

```js
{
  "compilerOptions": {
    "target": "ES5",
    "module": "commonjs",
    "removeComments": true,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "sourceMap": true
  },
  "files": [
    "app/app.ts"
  ]
}
```

All the files specific to our application will live inside the `app` subdirectory. There, we need to provide a `package.json` file that will simply tell Electron which script to use for bootstrapping. This will be the `main.js` file, and in it, we will tell Electron how to open and close our app.

```js
// app/package.json

...

{
  "name": "image-size-calculator-app",
  "version": "0.0.1",
  "main": "main.js"
}

...
```

Now let's configure the application window.

```js
// app/main.js

var app = require('app');

// browser-window creates a native window
var BrowserWindow = require('browser-window');
var mainWindow = null;

app.on('window-all-closed', function () {
  if (process.platform != 'darwin') {
    app.quit();
  }
});

app.on('ready', function () {

  // Initialize the window to our specified dimensions
  mainWindow = new BrowserWindow({ width: 1200, height: 900 });

  // Tell Electron where to load the entry point from
  mainWindow.loadURL('file://' + __dirname + '/index.html');

  // Clear out the main window when the app is closed
  mainWindow.on('closed', function () {

    mainWindow = null;

  });

});
```

The `main.js` script is really just some boilerplate that Electron needs to fire up. We are keeping a reference to `mainWindow` so that garbage collection doesn't interfere and close the window on us. We create a browser window with specific dimensions and then load an `index.html` file from the `app` directory. Let's create this file next.

Just like with a regular web app, we need an `index.html` entry point.

```html
  

  <html>
    <head>
      <meta charset="UTF-8">
      <title>Image Size Calculator</title>
      <link rel="stylesheet" href="../node_modules/bootstrap/dist/css/bootstrap.min.css">
    </head>
    <body>

      <div class="container">
        <h1>Hello Electron</h1>
      </div>

      <script src="../node_modules/angular2/bundles/angular2-polyfills.js"></script>
      <script src="../build/common.js"></script>
      <script src="../build/angular2.js"></script>
      <script src="../build/app.js"></script>
    </body>
  </html>
```

Aside from `angular2-polyfills.js`, The scripts that we're referencing aren't actually there yet, and that's because we haven't run our `webpack` command to generate them. The last thing we need to do before bundling our scripts is to create an empty `app.ts` file, as this is what our `webpack.config.js` file expects.

With an empty `app.ts` in place, let's bundle the scripts.

```bash
npm run watch
```

This command was set up in our `package.json` file in the project root, and it runs `webpack` with some options. One of these options is to watch for changes, so we can now edit our `app.ts` file and everything will automatically get bundled again.

If we look in our project root, we should now see our `build` directory. With all these files in place, we should be able to run the app. Remember that we've set up a command in our `package.json` file to do this.

```bash
npm run electron
```

If everything is wired up properly, we should now see our "Hello Electron" message.

![image-size-calculator app angular2 electron](https://images.ctfassets.net/23aumh6u8s0i/3KaDOlbF2X37s1KJ0b3dJu/fded35bbeaeff006121565f3de209d61/angular2-electron-1)

Yikes, that was a lot of boilerplate needed just to set things up! It's worth noting that a lot of this was just to set up Angular 2 and wasn't because of Electron specifically. If we were using a simpler framework (e.g., no TypeScript) or just plain JavaScript, then we wouldn't have needed as much boilerplate. The good news is that all we need to worry about now is the actual Angular 2 code. It's time to start building the app just as we would if it were on the web!

## Creating the Image Uploader

Our simple app will let users drop images in so that they can find out their sizes. Why wouldn't they just check the image's properties? Good point. However, this app will give us a chance to see how Electron adapts web APIs for the desktop.

Let's create the dropzone first. We'll do all of our Angular 2 work in one top-level component.

```js
// app/app.ts

import {bootstrap} from 'angular2/platform/browser';
import {Component} from 'angular2/core';
import {NgFor} from 'angular2/common';

@Component({
  selector: 'app',
  template: `
    <div
      (dragover)="false"
      (dragend)="false"
      (drop)="handleDrop($event)"
      style="height: 300px; border: 5px dotted #ccc;">
      <p style="margin: 10px; text-align: center">
        <strong>Drop Your Images Here</strong>
      </p>
    </div>
  `
})

export class App {

  constructor() {}

  handleDrop(e) {
    var files:File = e.dataTransfer.files;
    Object.keys(files).forEach((key) => {
      console.log(files[key]);
    });

    return false;
  }

}

bootstrap(App);
```

```html
  

  ...

  <div class="container">
    <app></app>
  </div>

  ...
```

To define some custom behavior for dropping an image into our app, we need to first pass `false` to the `dragover` and `dragend` events. The `drop` event is what we want to hook into, and for now we are simply logging out the details of the images we drop. That's right--we can see the same dev tools that we would in Chrome. If you're on a Mac, just do `Option + Command + I` to open them up.

Note that to get hold of the event information for the drop, we pass `$event`, just like we would in Angular 1.x.

![image-size-calculator app angular2 electron](https://images.ctfassets.net/23aumh6u8s0i/7nt2TZsoTBz2ZqQa6jZvYi/bc67dffc61a0d6496b158793cc4e3bd0/angular2-electron-2)

So how are we getting this information, exactly? Electron provides an abstraction around native files so that we can use the HTML5 file API. With this, we get the path to the file on the filesystem. This is useful in our case, because we can link to our images and show them in our app. Let's set that up now.

## Displaying the Images

Let's now put in some templating to display the images. For this, we'll want to use `ngFor` to iterate over the images we drop in.

> **Note:** As of Beta, templates are now case-sensitive. This means that what used to be `ng-for` is now `ngFor`.

```js
// app/app.ts

...

  template: `
    <div class="media" *ngFor="#image of images">
      <div class="media-left">
        <a href="#">
          <img class="media-object" src="{{ "{{ image.path " }}}}" style="max-width:200px"/>
        </a>
      </div>
      <div class="media-body">
        <h4 class="media-heading">{{ "{{ image.name " }}}}</h4>
        <p>{{ "{{ image.size " }}}} bytes</p>
      </div>
    </div>
`

...

export class App {

  images:Array<Object> = [];

  constructor() {}

  handleDrop(e) {
    var files:File = e.dataTransfer.files;
    var self = this;
    Object.keys(files).forEach((key) => {
      if(files[key].type === "image/png" || files[key].type === "image/jpeg") {
        self.images.push(files[key]);
      }
      else {
        alert("File must be a PNG or JPEG!");
      }
    });

    return false;
  }

}

...
```

Now we push the dropped files onto an array called `images` and iterate over it in our template to get the details. To avoid other file types being dropped in, we are only accepting `png` and `jpeg`.

![image-size-calculator app angular2 electron](https://images.ctfassets.net/23aumh6u8s0i/75fUdePu8wSB9bM6BhTKV1/3ca9251b245cdb7f2576c942c17d5590/angular2-electron-3)

## Getting the Image Stats

We want to have a way to display the total number of images dropped into the app, as well as the total size of those images. For this, we can create an `imageStats` function that returns these details.

```js
// app/app.ts

...

  template: `
    <h1>Total Images: {{ "{{ imageStats().count " }}}}</h1>
    <h1>Total Size: {{ "{{ imageStats().size " }}}} bytes</h1>
  `
...

  imageStats() {

    let sizes:Array<Number> = [];
    let totalSize:number = 0;

    this
      .images
      .forEach((image:File) => sizes.push(image.size));

    sizes
      .forEach((size:number) => totalSize += size);

    return {
      size: totalSize,
      count: this.images.length
    }

  }

...
```

![image-size-calculator app angular2 electron](https://images.ctfassets.net/23aumh6u8s0i/65q7cneMZuaXcNthZwWOQ8/3a9df1aa3f362386abf251a7bb29c751/angular2-electron-4)

## Adding a Byte Conversion Pipe

We're getting the number of bytes for each image, but ideally we would be able to get them in different units. It would be great if we had something to automatically convert the bytes to KB, MB, and GB, and display the appropriate units. We can do this easily with a custom pipe.

```js
// app/app.ts

import {bootstrap} from 'angular2/platform/browser';
import {Component, Pipe, PipeTransform} from 'angular2/core';
import {NgFor} from 'angular2/common';

@Pipe({ name: 'byteFormat'})
class ByteFormatPipe implements PipeTransform {
  // Credit: http://stackoverflow.com/a/18650828
  transform(bytes, args) {
    if(bytes == 0) return '0 Bytes';
    var k = 1000;
    var sizes = ['Bytes', 'KB', 'MB', 'GB'];
    var i = Math.floor(Math.log(bytes) / Math.log(k));
    return (bytes / Math.pow(k, i)).toFixed(1) + ' ' + sizes[i];
  }
}

@Component({
  selector: 'app',
  pipes: [ByteFormatPipe],
  template: `
    <h1>Total Images: {{ "{{ imageStats().count " }}}}</h1>
    <h1>Total Size: {{ "{{ imageStats().size | byteFormat " }}}}</h1>
  `
...
```

This pipe checks for the file size in bytes and returns the appropriate conversion. We then just apply the pipe to our template and we're able to get the desired output.

![image-size-calculator app angular2 electron](https://images.ctfassets.net/23aumh6u8s0i/2fBM1k5s9xBpjOreXjDQOI/448998a3ffed9dcb695e41f15324ab25/angular2-electron-5)

## Preparing for Distribution

When distributing Electron apps, it's essential to generate an archive of the application files so that the source code is concealed. This can be done with the `asar` utility.

<include src="TweetQuote" quoteText="When distributing Electron apps, generate an archive of the application files so that the source is concealed."/>

```bash
npm install -g asar
asar pack image-size-calculator app.asar
```

The archive file can then be used for the app, and it will be read-only.

We'll obviously want to change the name of the application and also provide a unique icon. Instructions for this, along with the other steps involved with distribution, can be found in the [Electron docs](http://electron.atom.io/docs/v0.35.0/tutorial/application-packaging/).

## Aside: Authentication with Auth0

No matter which framework you use with your Electron app, you can easily add authentication to it with Auth0! Our Lock widget allows you to get up and running quickly. Sign up for your <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">free Auth0 account</a> to work with these directions.

Before getting started with the code, you'll need to whitelist the `file://*` protocol in your Auth0 dashboard. This can be done in the **Allowed Origins (CORS)** area.

To begin, include the **Auth0-Lock** library from the CDN and provide a button or other element to hook into.

```html
  

  ...

  
  <script src="https://cdn.auth0.com/js/lock-7.12.min.js"></script>

  
  <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no" />

  <body>
    <h1>Authenticate with Auth0!</h1>
    <button id="login">Login</button>

  ...
```

Next, create a new instance of Lock and set `window.electron` to an empty object to trigger the proper login flow for Electron.

```html
  

  <script>

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

    window.electron = {};

  </script>
```

Finally, trigger the Lock widget to be shown when the user clicks the **Login** button. In the callback, set the returned user profile and token into local storage for use later.

```html
  

  <script>

    ...

    document.getElementById('login').addEventListener('click', function() {
      lock.show(function(err, profile, token) {
        if (err) {

          // Error callback
          console.error("Something went wrong: ", err);

        } else {

          // Success calback. Save the profile and JWT token.
          localStorage.setItem('profile', JSON.stringify(profile));
          localStorage.setItem('id_token', token);

        }
      });
    });

  </script>
```

> **Important API Security Note:** If you want to use Auth0 authentication to authorize _API requests_, note that you'll need to use [a flow that provides an access token](https://auth0.com/docs/api-auth/grant/implicit). Auth0 [`idToken` should only be used on the client-side, whereas access tokens should be used to authorize APIs](https://auth0.com/blog/why-should-use-accesstokens-to-secure-an-api/). You can read more about [making API calls with Auth0 here](https://auth0.com/docs/apis).
> 
> The way to attach the header to HTTP calls differs depending on which library or framework you're using. If you're using Angular v2+ in your Electron app, you can use **[angular2-jwt](https://www.npmjs.com/package/angular2-jwt)**. Follow the steps in the [Angular docs](https://auth0.com/docs/quickstart/spa/angular2/no-api) for more details. Not using Angular v2+? We have got [integrations](https://auth0.com/docs) for many other frameworks and libraries as well!

## Wrapping Up

Electron offers developers a way to create desktop applications with the web technologies they already know instead of needing to learn new languages that are specific to various operating systems. This is great, because skills can easily be ported, and code can be reused.

Electron doesn't care about which framework we use for our apps. Even though it's in beta, Angular 2 is a great framework to use inside an Electron app and, once everything is set up, works just the same as if we were developing for the web.

Create a Desktop App with Angular 2 and Electron

d48b998c2dce49ca309710eba498c562

Nathan Totten

Access Azure Storage APIs securely from browsers (i.e. using JavaScript) or native apps, without the need of a backend server.

**TL;DR**: you can access Azure Storage APIs securely from browsers (i.e. using JavaScript) or native apps, without the need of a backend server. Live demo @ <http://auth0.github.io/auth0-azure-blob-sample/>

---

Today’s modern cloud provides developers with a rich choice of building blocks for creating new and innovative applications faster than ever before. Utilizing Auth0, developers can build applications that are secure and scalable without the need for a traditional backend server. This significantly reduces your time to release as well as the cost of maintenance over the life of your application.

In this post you will see an example of how you can use Auth0 and the near infinite scale of Azure Blob Storage to build a rich and secure client application without a traditional backend. This example is built entirely in HTML/JavaScript and runs in the browser while still providing secure, authenticated access to resources in Azure Blob Storage.



Below you will find a simple diagram showing how this application will work. Notice that the browser app only communicates either with Auth0 or with blob storage directly. We don’t need backend server helping with security – Auth0 does this for us.

<div style="text-align: center"><img src="https://images.ctfassets.net/23aumh6u8s0i/7pUss8YHMqziXbR1kGgmH2/b2477c7d30bfcf8bafdea0305fe37234/cpLqCchdjHP_"/></div>

## Logging In

Authenticating with Auth0 is a breeze. To log the user in we will use the Auth0 Lock widget. After the user clicks through to login the callback will be returned and we can take the token and profile data and store them in the browser's local storage. After the data is stored, we redirect the user to the files.html page.

```js

var lock = new Auth0Lock(window.config.clientId, window.config.domain);

document.getElementById('btn-login').addEventListener('click', function() {
  lock.show({ popup: true }, function(err, profile, token) {
    if (err) {
      // Error callback
      alert('There was an error');
    } else {
      // Success calback

      // Save the JWT token.
      store.set('azure_sample_id_token', token);

      // Save the profile
      store.set('azure_sample_profile', JSON.stringify(profile));

      location.href = 'files.html';
    }
  });
});
```

## Retrieving the Azure Storage SAS Token
Auth0 integrates with a variety of identity providers as well as a number of additional services we call addons. We support a variety of addons such as [Firebase](https://auth0.com/docs/server-apis/firebase), [Salesforce](https://auth0.com/docs/server-apis/salesforce), [Azure Service Bus](https://auth0.com/docs/server-apis/azure-sb), and [Azure Storage](https://auth0.com/docs/server-apis/azure-blob-storage). You can use these addons to exchange your traditional user tokens for API specific tokens – in our example, we will use our JWT token issued by Auth0 for a Azure Blob SAS token in order for the browser client to securely read and write to storage.

```js
auth0.getDelegationToken({
  id_token: current_id_token,
  scope: "openid",
  api_type: "azure_blob",
  containerName: id_hash + "my-container-name"
}, function(err, delegationResult) {
  callback(delegationResult.azure_blob_sas);
});
```

## Rules
In addition to simply exchanging tokens we can use a feature in Auth0 called [Rules](https://auth0.com/docs/rules) to fully control user access to containers and blobs. Rules are Javascript functions that run on Auth0 in response to various authentication events. You can use rules to completely customize how authentication works inside your application.

In our example, I am simply limiting each user to a single blob that they own, but you could image that we could build a rich role-based access list for users to provide fine-grained control over storage resources. You can see the code for our rule below. Notice how we are using the Azure Storage SDK inside of the rule to check if containers exist and create new containers.

```js
function(user, context, callback) {

  var CLIENT_ID = "your_client_id_here";

  // Only run this rule for the correct app and for azure_blob delegations
  if (!(context.clientID === CLIENT_ID &&
        context.isDelegation &&
        context.request.body.api_type === 'azure_blob')) {
    return callback(null, user, context);
  }

  var blobName = context.request.body.blobName;
  var containerName = context.request.body.containerName;

  // Get user id hash
  var shasum = crypto.createHash('sha1');
  shasum.update(user.user_id);
  var hash = shasum.digest('hex');

  // Check to make sure the container belongs to the user
  if (containerName !== hash) {
    return callback(new UnauthorizedError('Not authorized.'));
  }

  // For blob requests, we are done
  if (blobName) {
    return callback(null, user, context);
  }

  var blobService = azure_storage.createBlobService(
    configuration.AZURE_STORAGE_ACCOUNT_NAME,
    configuration.AZURE_STORAGE_ACCOUNT_KEY);

  // For container list operations, ensure the container exists
  blobService.createContainerIfNotExists(containerName,
  function(error, result, response) {
    if (error) {
      return callback(error);
    }
    return callback(null, user, context);
  });  
}
```

## List Blobs in Container
Once we have our container’s SAS token, our browser app can make a request directly to Azure Blob storage to list the contents of the blob.

```js
var url = 'https://blobshare.blob.core.windows.net/' + containerName +
  '?' + sasToken + '&restype=container&comp=list';
$.ajax({
  url: url,
  type: "GET",
  success: function(data, status) {
    var model = convertResponseToModel(data);
    callback(null, model);
  },
  error: function(xhr, desc, err) {
    callback(err);
  }
});
```


## Upload a Blob
Because we want to be able to handle large files we are going to upload our file as a block blob. This allows the browser to make multiple requests to upload small chunks of a large file. This way, if one request fails we simply have to retry a small request rather than retry the entire upload. This means our browser app can handle uploads of very large sizes efficiently.

Once again, we will call our Auth0 delegation endpoint to exchange our auth token for an azure blob sas token. This token will be for a particular blob rather than a container. Because the code for uploading a blob in blocks is quite long I won’t put a snippet here. You can find a great reference on how to do that on [Gaurav Mantri’s blog](http://gauravmantri.com/2013/02/16/uploading-large-files-in-windows-azure-blob-storage-using-shared-access-signature-html-and-javascript/).

## Resources
Now that we have walked through the steps of building a secure client-only application with Azure Storage and Auth0 you can try out the [running application](http://auth0.github.io/auth0-azure-blob-sample/) yourself. Additionally, you can find the [full source](https://github.com/auth0/auth0-azure-blob-sample) on Github and [additional documentation](https://auth0.com/docs/server-apis/azure-blob-storage) about using Auth0 and Blob storage.

<div class="try-banner try-code" style="margin: 0">
    <a href="https://github.com/auth0/auth0-azure-blob-sample" target="_new" class="btn btn-default btn-lg"><i class=" icon-1392070209-icon-social-github icon"></i>Code</a>
    <a href="http://auth0.github.io/auth0-azure-blob-sample/" target="_new" class="btn btn-default btn-lg"><i class=" icon-budicon-698 icon"></i>Demo</a>
</div>

## Summary
I hope this post gave you an understanding of some of the awesome things you can do with Auth0 and the modern cloud. Be sure to sign up for your [free developer account](https://auth0.com/pricing) and check out our [quick start guides](https://auth0.com/docs). If you have any questions you can reach our entire team on [chat.auth0.com](http://chat.auth0.com/) or [@Auth0](http://twitter.com/auth0).

Using Azure Services without a Backend

b93af62499ed0f76f280acb37913f15d

Hernan Zalazar

A few weeks back we released the first version of our native iOS SDK to help you add authentication to your app. We needed a Keychain library that supported

A few weeks back we released **the first version of our native [iOS SDK](https://github.com/auth0/auth0.ios)** to help you add authentication to your app.

We needed a **Keychain library** that supported the following features:

* **TouchID Support**: An option to make a private keychain value only available if the user entered his fingerprint
* **Accessibility options**: An option to state wether the keychain value could be got if the iPhone is Locked, Unlocked or in which state
* **Shared Group**: We needed Shared Group support so that 2 different apps could share keychain values

As there was no library that fulfilled our needs, **we decided to build [SimpleKeychain](https://github.com/auth0/SimpleKeychain)**.

Let’s see some of the different use cases that we’ve created and used.



## How do I store a value (e.g. JWT Token) in the Keychain?

```objc
NSString *jwt = //user's JWT token obtained after login
[[A0SimpleKeychain keychain] setString:jwt forKey:@"auth0-user-jwt"];
```

```swift
let jwt = //user's JWT token obtained after login
A0SimpleKeychain.keychain().setString(jwt, forKey:"auth0-user-jwt")
```

## How do I share a value (e.g. JWT token) between different apps?

When you have a family of apps that need to share the same user session, you can use iOS Keychain Sharing to store the token. That token must be stored under the same Access Group.

First in one of your apps save the JWT token:

```swift
let keychain = A0SimpleKeychain.keychainWithService("Auth0", accessGroup: "ABCDEFG.com.mydomain.mysharegroup")
let jwt = //user's JWT token obtained after login
keychain.setString(jwt, forKey:"auth0-user-jwt")
```

Then, you obtain the token in the other app:

```swift
let keychain = A0SimpleKeychain.keychainWithService("Auth0", accessGroup: "ABCDEFG.com.mydomain.mysharegroup")
let jwt = keychain.stringForKey("auth0-user-jwt")
```

## How I can handle the accessibility of the items saved in the keychain?

If you want to restrict when the item can be retrieved (For example only when the iPhone is unlocked, or if you want the entry to be included in any backup) you need to specify the item accessibility before saving:

```objc
A0SimpleKeychain *keychain = [A0SimpleKeychain  keychain];
keychain.defaultAccessibility = A0SimpleKeychainItemAccessibleWhenUnlockedThisDeviceOnly;
NSString *jwt = //user's JWT token obtained after login
[keychain setString:jwt forKey:@"auth0-user-jwt"];
```

## How can I trigger TouchID prompt before accessing the Keychain?

With the release of iOS 8, a new feature was added in order to tie a Keychain item to the user's passcode or their fingerprints .In order to use this feature, you need to store the value with accesibility `A0SimpleKeychainItemAccessibleWhenPasscodeSetThisDeviceOnly` and using iOS 8 Keychain Access Control:

```swift
let keychain = A0SimpleKeychain.keychain()
keychain.defaultAccesiblity = .WhenPasscodeSetThisDeviceOnly
keychain.useAccessControl = true
let jwt = //user's JWT token obtained after login
keychain.setString(jwt, forKey:"auth0-user-jwt")
```

Then whenever you query for that item a prompt will appear and the user will have to enter their fingerprint or passcode:

```swift
let message = NSLocalizedString("Please enter your passcode/fingerprint to login with awesome App!.", comment: "Prompt TouchID message")
let keychain = A0SimpleKeychain.keychain()
let jwt = keychain.stringForKey("auth0-user-jwt", promptMessage:message)
```

This is just a glimpse of all that you can accomplish with [SimpleKeychain](https://github.com/auth0/SimpleKeychain).

Add it to your **Swift or Objective C** project now with CocoaPods and start using it!:


```ruby
pod 'SimpleKeychain', '~> 0.1'
```

"native"