API authorization

[M-Paladin]

Hello,

I feel really stupid because with rested and firefox I manage to create an authentication token and use it.

I'm unable to reproduce this using curl

I read oauth docs and tried obtaining an Authorization Code in order to request an acces token but no response since the beginning
I also tried refreshing an existing code but I can't find the good syntax either

Can someone help me ?

Regards

[M-Paladin]

Ok so finally, I managed to understand and use correctly the full process thanks to :
#1559
#2419
https://auth0.com/docs/flows/call-your-api-using-the-authorization-code-flow#authorize-user

Before I was using a personnal access token but I had the bad surprise it expired so I worked hard and found another solution.

First, I create an OAuth Client with a secret in http://<firefly-iii_server>/profile.
The callback URL will be http://empty as it's not really used.

Once it's done, I open a new page in my web browser and go to :
http://<firefly-iii_server>/oauth/authorize?response_type=code&client_id=<id_oauth_client>&redirect_uri=http://empty&scope=&state=

I'm asked if I authorize the access or not, so I authorize.
The URL is redirected to :
http://empty?code=<a_long_hexadecimal_code>

This code is important because it allows to ask for a token
Using a linux terminal :

curl --request POST \
  --url 'http://<firefly-iii_server>/oauth/token' \
  --header 'content-type: application/x-www-form-urlencoded' \
  --data grant_type=authorization_code \
  --data 'client_id=<id_oauth_client>' \
  --data client_secret=<password_oauth_client> \
  --data code=<a_long_hexadecimal_code> \
  --data 'redirect_uri=http://empty'

In response you will receive something like this

{
  "token_type": "Bearer",
  "expires_in": 1209600,
  "access_token": "<a_long_hexadecimal_access_token>",
  "refresh_token": "<a_long_hexadecimal_refresh_token>"
} 

Both tokens are very important for using API
The access token is used to call API directly to execute things
For example, get a list of recurring transactions

curl \
  --silent \
  -L \
  --header "Authorization: Bearer <a_long_hexadecimal_access_token>" \
  --header 'Accept: application/json' \
  --request GET \
  'http://<firefly-iii_server>/api/v1/recurrences'

The refresh token can be use to renew the access token without using the whole process again

curl --request POST \
  --url 'http://<firefly-iii_server>/oauth/token' \
  --header 'content-type: application/x-www-form-urlencoded' \
  --data grant_type=refresh_token \
  --data 'client_id=<id_oauth_client>' \
  --data client_secret=<password_oauth_client> \
  --data refresh_token=<a_long_hexadecimal_refresh_token>

In response you obtain a new access token and a new refresh token so you can continue the process as long as you want !

For example, each month, I generate my recurring transactions with a script calling API.
Each time I begin with refreshing the token, getting the new access token, storing the refresh token for the next time.
After that the process really start.

I hope this will be helpful for those who are using API because I found it really hard to understand and create properly the whole process.
Good luck with API everyone.

[Terry-JF]

Hi M-Paladin,
I found this really useful, thanks. I have everything working except for the very last step - using the refresh token. The curl request receives back:
{
"error":"invalid_request",
"error_description":"The refresh token is invalid.",
"hint":"Cannot decrypt the refresh token",
"message":"The refresh token is invalid."
}
I have generated 3 different access_token/refresh_token pairs and get the same result with every refresh token, though the access tokens work fine. Are you still using this mechanism to get and use refresh tokens?
Many thanks for any help, Terry

[M-Paladin]

Hi Terry-JF,
I'm still using this mecanism yes, it works fine so far.
However, I use an old version (5.6.8) and well, as it's not so straightforward to upgrade, I'm sticking with it right now (I plan to move on docker one day)
Unfortunately, I don't know what to say more because I've never seen this error. If you respect exactly the syntax, you should be able to see the same results that I have I suppose, unless the newer versions don't deal with it properly.
So if you have the possibility/time, try with the same version that I have, if it works, try with different versions progressing to the one you currently use and well, maybe you found a bug.