API: Authentication

External application can access the 88 Miles API using OAuth 2.0. OAuth is a token based authentication system, which means your users can access their 88 Miles data without having to give you their username or password.
Many popular languages already support OAuth 20, which should ease integration with you application. You can see if your favourite language is supported on the
OAuth website.

Using an existing library will speed up your development, so it is recommended you have a look at one first. If you are interested in how the protocol works, or
need more information to debug the require process, read on…

Authorization Grants

Authorization code

The Authorization code strategy should be used if you can keep the client secret private. This will be the case if you are accessing the API via a web server, which will be able to store your client id and secret securely.
You must first request a verification token, whch can be exchanged for an access token.

The Verification Token

To give your application access to a user's 88 Miles account, they will first need to verifier who they are. To do this, redirect the user to the authorize URL, with the following parameters:

client_id
The client id supplied to you when you registered

Required

client_secret
The client secret supplied to you when you registered

Required

redirect_uri
The callback url you supplied to you when you registered

Required

state
A string that will get passed back to you so you can track the request

Implicit

If you are integrating 88 Miles inside a browser, or in a desktop or mobile app, where you can't guarentee the secret token can be kept secret, you may use the implicit grant type, which doesn't require the secret token.
An access token will be returned straight away as a hash component when redirecting back to your callback_url.

You need to include the following parameters in your authorize URL:

client_id
The client id supplied to you when you registered

Required

response_type
Set to token

Required

redirect_uri
The callback url you supplied to you when you registered

Required

state
A string that will get passed back to you so you can track the request

Optional

Web apps can simply redirect to the token URL. For desktop and mobile apps, you will need to open an embedded browser instance — check your language's documentation on how to do this.

Password

You may use the password grant, however, it is not recommended. It can be helpful when debugging or for accessing data from the command line, or if you can't easily provide a callback URL. Don't ever store a users login or password. That is why you are requesting an access token!

You will need to hit the token URL, rather than the authorize URL.

You need to supply the following parameters

client_id
The client id supplied to you when you registered

Required

client_secret
The client secret supplied to you when you registered

Required

grant_type
Set to password

Required

response_type
Set to token

Required

username
The user's login

Required

password
The user's password

Required

state
A string that will get passed back to you so you can track the request