Developing a web or native App with OAuth2 and PKCE
Single page web applications or native apps cannot keep their client secrets private and are therefor called public clients. For such cases the client secret can be omitted by relying on PKCE.
Before we can start, we need to make sure that our ilert application is configured correctly.
Navigate to your application and make sure that you have entered a redirect url that fits your local or deployed webapp. Also copy the client id, as we will need it to configure your application.
Redirecting the user
Using the parameters generated by ilert during the creation of our app, we can build a redirect url for our application, that will take unauthorized users to ilert and ask them to login and grant their permission for our app. In the case of our app, we ask for the profile scope (find more information on other available scopes here), as well as the source:w scope which will grant us permission to read the user's profile data, as well as to read and edit alert sources on behalf of the authorizing user.
Make sure that the redirect_uri that is passed to the redirect url is exactly the same as the one the you have entered in your application's settings or the authorization will fail. This validation is necessary, as verifing the redirect_uri is a very important part of implementing a secure OAuth2 flow. In case you need to send optional data e.g. your own id, use the state query parameter. It will be returned to your client.
Also note that per default for PKCE-only clients no refresh token will be issued, unless the additional offline access scope is requested. Please keep refresh tokens secure.
PKCE generation
Before redirecting the user to the ilert authorization server, we need to generate a verifier and code challenge that can be used by the authorization server to ensure the origin of the (later) token request matches the origin of the authorization request.
PKCE might seem confusing at first, but in the end it is just a random identifier that verifies that the one who initially started the authorization request, is the same who comes asking for the token. And to ensure noone else knows the plain version of the identifier it is hashed before sharing it with the authorization server.
Below are helper methods to deal with PKCE generation:
Notice how we are storing the verifier in the session storage, as we will need it later to verify to the authorization server that we are the same ones who initiated the authorize request.
With our verifier and code challenge in place, we can create our redirect url:
In case the user is known to your application or especially if the application is limited to a single account. We suggest to redirect the user directly to the tenant (account url) of the user, this way he might be able to skip the login step if logged in already. e.g. https://someTenant.ilert.com/api/developers/oauth2/authorize instead of https://app.ilert.com/api/developers/...
User grant view
The user will be able to see the scopes that you have requested and grant them.
In case of an error
In case of any error, ilert's authorization server will send the user back to the provided redirect_uri while adding an error and error_description query parameter to it.
In case of successful authorization
If the user has accepted your scopes, ilert's authorization server will redirect the user back to your provided redirect_uri while adding a code query parameter to it. This code parameter can be used in the next step to fetch the access token.
Your application should store the access and especially the refresh token as safely as possible. You can now make requests to ilert's API on behalf of the authorized user.
Do not forget the Bearer prefix in the authorization header before your access token.
As access tokens are short lived (read more about token lifetime here), you will have to refresh them regularly, at least in case they expire and the ilert API returns a 401 HTTP status code error.
Just like the user may at any time revoke the refresh token that was issued to your application, your application may also proactively revoke the refresh token.