Great I’ll have a look. If they’re not the same, why would that be?
The state session variable is changing with every new login. (not at my computer right now so I can’t check the query string)
The state is indeed random with every login, this is an extra security layer to prevent xsrf attacks. When you are redirected back it should have the state and code in the url. First the state is being checked if it is the same as the one in the session and then the code is being checked by making an other call to the external service and that should return the access_token.
For some reason, the login and authorize steps are getting repeated twice (nothing is doubled up anywhere steps wise, and it’s just a straight link to the login), and the second time around a different state value is returned, but the first one is the one that is saved in the session variable.
Any ideas why it’s repeating the process?
Thanks Jon
Do you perhaps have the Oauth provider action inside the api, along with the authorize action? I could see how that might cause it to authorize twice. The provider should only be set under Globals.
No it’s just the authorize step and redirect back to the sending page.
If I remove the redirect (and set the authorize to output ) I get all the token information, but it still authorizes twice.
If I turn the output off its still authorizes twice.
Definitely feeling confused by this one!
Okay, now I notice that the client_id may be different for the two? They are partially redacted, but appear to be different. Maybe that will help you find the issue.
When you say you’re redirecting to the sending page, is that in any way the same page the action starts with? Ie, are you coming back to your initiating point and retriggering the authentication worklow?
If it’s the case, try having something like login.php redirect to index.php. Your login.php handles an authentication step based on your Graph Api output, which allows to protect your index.php within wappler native workflow.
The client_id is the same on both authorize requests (just shows up funny in chrome).
The redirect is back to the index page (where the standard html link to the authorize flow is) so once redirected just loads the page you came from.
Not sure what to try next!
That may be the problem, I typically have a login page and an index page. If I can free a block of a few hours tomorrow, I’ll put together a sample login project that maybe can help you out - if it works in your environment, you can modify it to your needs.
Hi Patrick,
Just having. my first attempt at using Microsoft for login. I can get the oAuth2 step returning the code which then redirects to another page (with the code as a parameter) - I can’t see how that is the next call is made to get the access token. Subsequent API calls, using the oAuth2 authentication result in
{"error":{"code":"InvalidAuthenticationToken","message":"Access token is empty." ...
I have tried inserting the entire response from the auth step and then the access_token value from the auth step into the DB but neither appear to contain anything or it is redirecting before getting to this step:
What is the best way of getting to the access token?
Thanks Keith,
The authorisation is called fine using the oAuth2 step and redirects to the URI but I can’t see how the access the token to make subsequent calls like to the me endpoint
Is the OAuth step set to manual or session?
I think I’m getting somewhere - understanding the auth flow
What I mistakenly thought:
The redirect URI was the address the user was sent to once authorized from another API step (which is partly true)
What it actually is:
The address the user goes to that initiates the authorisation. Once the initial MS login and permission approval has been made its is redirected to the same place with a code as a GET parameter that the same API step uses to retrieve an access token. Once retrieved you can store what you need in a DB, run API calls using the OAuth2 provider etc and redirect to a dashboard/portal/members area.
It was the looping back to the same place I was missing and that the same step handles the request for authorisation and turning the response code into an access token.
Yes, when you make the call to Microsoft you pass the URL you want it to redirect to in your app and process the returned code. It doesn’t have to be the same page you used to call Microsoft.