# A library that authenticates Azure JWT tokens asynchronously. An updated fork of [azure-jwt](https://github.com/cfsamson/azure-jwt)  

[![Crates.io](https://img.shields.io/crates/v/azure_jwt_async.svg)](https://crates.io/crates/azure_jwt_async)
[![Chrono on docs.rs][docsrs-image]][docsrs]

[docsrs-image]: https://docs.rs/azure_jwt_async/badge.svg
[docsrs]: https://docs.rs/azure_jwt_async

This library will fetch public keys from Microsoft and use those keys to validate the
authenticity of a token you provide. It defaults to validating and mapping Azure Id tokens for
you out of the box.

Azures public keys are fetched by sending request for them through the open-connect api. The default is to expire the stored keys after
24 hours and fetch new ones since that correspond with the normal key rotation scheme. There is also a default retry fallback
where a `kid` that doesn't match any of our current public keys wil trigger _one_ refresh of the keys (limited to once an hour),
just in case the set default is badly synced with the rotation of the public keys or Microsoft decides to rotate the keys
immediately for some reason. Both of these settings can be configured.

## Example

```rust

let client_id = "my client id from Azure";
let mut az_auth = AzureAuth::new(client_id).await.unwrap();

let decoded = az_auth.validate_token(TEST_TOKEN).await?;

```

## Performance

When you create a new `AzureAuth` instance in its default configuration it will trigger two calls
to Microsoft endpoints (one to get the open connect metadata to get the current jwks_uri and one to
fetch the jwk sets). You should create these objects with care and prefer using a reference to one
instance. If you're using it on a webserver you should avoid creating a new instance on every connection
and rather instantiate one on server start and use a mutex or channels to do validation. Once the keys
are loaded the operations should be very fast.  

## Security

**This library validates six things:**

1. That the token is issued by Azure and is not tampered with
2. That this token is issued for use in your application
3. That the token is not expired
4. That the token is not used before it's valid
5. That the token is not issued in the future
6. That the algorithm the token header specifies the right algorithm*

* Note that we do NOT use the token header to set the algorithm for us, look [at this article for more information on why that would be bad](https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/)

The validation will `Error` on a failed validation providing more granularity for library users to find out why the token
was rejected.

**You'll need:**

You will need a [private client_id created by Azure for your application][link2] to be able to verify that
the token is created for your application (and not anyone with a valid Azure token can log in). This is the ID this library
needs from you to authenticate that the token vas issued for your application.

You get a verified token parsed for you in return.

**You still must take care of:**

1. Validating that the user has the right access to your system
2. Validating any other information that is important for your use case
3. If you ask for more information about the user than what is defined in [Microsoft ID tokens reference][link1] you will need
to make a Struct that maps to all the fields in the token and use the `custom_validation` method.

For more information, see this article: <https://docs.microsoft.com/en-us/azure/active-directory/develop/id-tokens>

[link1]: https://docs.microsoft.com/en-us/azure/active-directory/develop/id-tokens
[link2]: https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal