# Vert.x Auth - Authentication and Authorisation

This Vert.x component provides interfaces for authentication and authorisation that can be used from your Vert.x applications and can be backed by different providers.

Vert.x auth is also used by vertx-web to handle its authentication and authorisation.

To use this project, add the following dependency to the dependencies section of your build descriptor:

- Maven (in your `pom.xml`):

    <dependency>
      <groupId>io.vertx</groupId>
      <artifactId>vertx-auth-common</artifactId>
      <version>3.3.3</version>
    </dependency>

- Gradle (in your `build.gradle` file):

    compile 'io.vertx:vertx-auth-common:3.3.3'

## Basic concepts

Authentication means verifying the identity of a user.

Authorisation means verifying a user has an authority.

What the authority means is determined by the particular implementation and we don’t mandate any particular model, e.g. a permissions/roles model, to keep things very flexible.

For some implementations an authority might represent a permission, for example the authority to access all printers, or a specific printer. Other implementations must support roles too, and will often represent this by prefixing the authority with something like `role:`, e.g. `role:admin`. Another implementation might have a completely different model of representing authorities.

To find out what a particular auth provider expects, consult the documentation for that auth provider..

## Authentication

To authenticate a user you use `authenticate`.

The first argument is a JSON object which contains authentication information. What this actually contains depends on the specific implementation; for a simple username/password based authentication it might contain something like:

    {
      "username": "tim"
      "password": "mypassword"
    }

For an implementation based on JWT token or OAuth bearer tokens it might contain the token information.

Authentication occurs asynchronously and the result is passed to the user on the result handler that was provided in the call. The async result contains an instance of `User` which represents the authenticated user and contains operations which allow the user to be authorised.

Here’s an example of authenticating a user using a simple username/password implementation:

    JsonObject authInfo = new JsonObject().put("username", "tim").put("password", "mypassword");

    authProvider.authenticate(authInfo, res -> {
      if (res.succeeded()) {

        User user = res.result();

        System.out.println("User " + user.principal() + " is now authenticated");

      } else {
        res.cause().printStackTrace();
      }
    });

## Authorisation

Once you have an `User` instance you can call methods on it to authorise it.

to check if a user has a specific authority you use `isAuthorised`.

The results of all the above are provided asynchronously in the handler.

Here’s an example of authorising a user:

    user.isAuthorised("printers:printer1234", res -> {
      if (res.succeeded()) {

        boolean hasAuthority = res.result();

        if (hasAuthority) {
          System.out.println("User has the authority");
        } else {
          System.out.println("User does not have the authority");
        }

      } else {
        res.cause().printStackTrace();
      }
    });

And another example of authorising in a roles based model which uses `role:` as a prefix.

Please note, as discussed above how the authority string is interpreted is completely determined by the underlying implementation and Vert.x makes no assumptions here.

### Caching authorities

The user object will cache any authorities so subsequently calls to check if it has the same authorities will result in the underlying provider being called.

In order to clear the internal cache you can use `clearCache`.

### The User Principal

You can get the Principal corresponding to the authenticated user with `principal`.

What this returns depends on the underlying implementation.

## Creating your own auth implementation

If you wish to create your own auth provider you should implement the `AuthProvider` interface.

We provide an abstract implementation of user called `AbstractUser` which you can subclass to make your user implementation. This contains the caching logic so you don’t have to implement that yourself.

If you wish your user objects to be clusterable you should make sure they implement `ClusterSerializable`. <a href="mailto:julien@julienviet.com">Julien Viet</a><a href="http://tfox.org">Tim Fox</a>