🔒 Authorization
How to use OAuth2 to request access for your application
Last updated
How to use OAuth2 to request access for your application
Last updated
Your bitcoin & nostr companion / from 🐝 with 🧡
All Alby API endpoints are secured by OAuth 2.0. Follow these steps in order to allow a user to authorize your application and obtain a token that you can use to access the API on their behalf.
If you want to programmatically access your own Alby account, create an access token and use it as an Authorization header when making API calls:
Authorization: Bearer YOUR_ACCESS_TOKEN
Login to your account on getalby.com and create a new API client here:
Set Application URL
and Callback URL
to http://localhost:YOUR_PORT_NUMBER
for local development. You can provide a placeholder image if you don't have one for your app yet.
If you are hosting your application, make sure the domain you enter in the callback URL field exactly matches the domain you are hosting your application.
Endpoints
Authorization URI https://getalby.com/oauth
Token URI https://api.getalby.com/oauth/token
Redirect your users to the following URL:
https://getalby.com/oauth?client_id=YOUR_CLIENT_ID&response_type=code&redirect_uri=YOUR_CALLBACK_URL&scope=<scope>
To redirect the user to a specific page or endpoint in your app, instead of passing your domain as the callback URL (e.g. http://localhost:8080), include a path such as http://localhost:8080/auth/callback
client_id
The Client ID of your credentials.
client_response_type
(code
is used for this type of authentication)
redirect_uri
The URI the user should be redirected to after successful authentication. This usually points to your application.
scope
See here for available options.
state
(optional)
This parameter will be returned to the callback URI.
The redirect should be done using a native browser with a URL bar, not with an embedded webview, so users are able to verify that they are being redirected to the correct URL.
Scopes allow you to request fine-grained access permissions for your application. The following scopes are available:
account:read
Request the user's Lightning Address and their keysend information.
invoices:create
: Create invoices on a user's behalf.
invoices:read
: Read a user's incoming transaction history.
transactions:read
: Read a user's outgoing transaction history.
balance:read
: Read a user's balance.
payments:send
: Send payments on behalf of a user.
You can also request multiple scopes by space-separating and URL encoding them:
...&scope=account:read%20balance:read
If successful, the user will be redirected and your redirect URI will be loaded with a code
parameter:
After users have confirmed your request they will be redirected to the redirect_uri
you provided. An additional parameter code
will be appended which you will need to exchange for an access token.
OAuth 2.0 is a well recognized standard for authentication. Chances are high there is a library available for your application stack that allows you to integrate OAuth 2.0 without much hassle.
Clients that would need to store their client_secret
in a place that is accessible by end-users, for example pure browser-based or mobile apps should use the PKCE extension flow to protect against interception of the authorization code. To do this, before redirecting your users, create a random string between 43-128 characters long, then generate the url-safe base64-encoded SHA256 hash of the string. The original random string is known as the code_verifier
, and the hashed version is known as the code_challenge
.
In the redirect URL, add 2 extra fields:
code_challenge
with the hash and
code_challenge_method=S256
.
Store the code_verifier
in local storage, so that you can access it for the 2nd step, after the callback URL has returned. So the request would be:
https://getalby.com/oauth?client_id=YOUR_CLIENT_ID&code_challenge=<CODE_CHALLENGE>&code_challenge_method=S256&response_type=code&redirect_uri=http://localhost:8080&scope=<scope>
In the 2nd request, you should add code_verifier
as an extra field. This helps to protect against the authorization code being intercepted and used by malicious software to acquire an access token.
Run this in a browser. You are redirected to localhost, so you need to run a server or you need to re-open the static html file and paste the code callback manually after you’ve been redirected.
Make a HTTP POST using form-data (Content-Type: application/x-www-form-urlencoded
), including the previously obtained code
and use the client credentials as basic authentication. In case of a client that cannot use the client secret, use the empty string instead.
It is also possible to send the client credentials in the http form parameters, instead of using basic authentication. Use client_id
and client_secret
as the field names. Replace redirect_uri
with your app callback url.
The response will be:
You can then use this access_token
to make API requests.
The access token should be used as an Authorization header when making subsequent API calls
Authorization: Bearer $access_token
A refresh token can only be refreshed once (returning a new request token and access token). Make sure to avoid race conditions (e.g. two requests to refresh a token in parallel) as subsequent requests will return an invalid_grant error. The Alby JS SDK handles this automatically for you. If you're having trouble with a custom implementation, don't hesitate to reach out.
Use the refresh token to obtain a new access token / refresh token.
Requests using expired or invalid access tokens will result in an error like:
You can use an OAuth token to query information about its client id, its redirect uri and its scopes: