Is there a step that I'm missing here in order to be able to set this up correctly to get a refresh token using the apps identity rather than the user's identity for our organization? This is urgent so if I could get a little assistance being walked through this, I have referred to every possible other forum post as well as the docs for implementing refreshed access tokens via the apps identity over the user within Retool docs and Microsoft Graph API docs. Thanks in advance!
From a quick glance it looks like you have everything set up correctly on the Retool end.
Are you able to pass in all the same user credentials to Microsoft Graph API using another service like Postman and able receive valid tokens back?
Given that the Microsoft API's server is responding with an error message stating that the "scope User.write does not exist in the resource" leads me to believe that the issue might be related to permissions of the Microsoft account with the user's credentials that are being passed in.
Given that the defined variables all appear with a status of Exists:No I would assume that the result of you clicking "Check authentication status using current credentials" is a bug giving a false positive, which I can test out and file a bug report for.
So other tasks prevailed and I haven't come back to this in about a week -- yet I did notice a couple discrepancies from the screenshots I provided. Even after rectifying then, however, I was still not able to successfully get either a token or a refresh token
I'll peek back into this today -- I got frustrated and put it down while I completed some other important tasks but this is of paramount importance for my work to get auth delegated through the apps identity rather than the user. I don't have privileges to view things like the client key other than through magic strings provided from our Retool settings.
At first when the callback URI wasn't matching our IT Director added the one specified in our callback URL but that also didn't bring back a successful result.
If I can figure this out, though, it'll be a huge win for myself and our company
I had something similar to this set up previously -- but thought this was set to use the user's identity and not the app identity in the background without the need of prompting the user, correct?
Am I out of scope with that assumption? Forgive my lack of knowledge on MSGraph haha it's been awhile since I've worked with auth configurations. Having it set up through client credentials, though, is not what our company is wanting if I am indeed understanding that correctly...but I'd love some enlightenment if what I'm stating seems inaccurate
The OAuth 2.0 client credentials grant flow permits a web service to use its own credentials, instead of impersonating a user to authenticate when calling another web service.
This type is commonly used for server-to-server interactions that must run in the background, without immediate interaction with a user
In the client credentials flow, permissions are granted directly to the application itself by an administrator. When the app presents a token to a resource, the resource enforces that the app itself has authorization to perform an action since there is no user involved in the authentication.
Basically, client credentials just means using an app's identity as the means of authentication and NOT the user's.
Which DOES sound like what you're after here, if I'm understanding your post correctly?
@mitchmess thank you so much for your quick responses today!
If this non-custom setup also takes care of the process of a second post method which grants a refresh token once it has expired, and not only getting the initial token?
If so -- then after confirmation from our senior engineer I would say this is the solution! Which is funny -- as I had this setup originally, thinking it was working before creating a custom auth workflow -- but thought I was told something along the lines of that not fetching a refresh token upon an original access token expiring... Which may have also been a misunderstanding on my part!
Again, I appreciate all of the clarity you are providing so I can be more familiar with the "why" without re-looking at documentation that seemed to have many moving parts and options on how to designate auth!
If the access token request is valid and authorized, the authorization server issues an access token as described in Section 5.1. A refresh token SHOULD NOT be included.
Thank you so much for the insight! I'm waiting to hear confirmation back from my senior -- but this seems to be a pretty surefire solution until I know for sure.
As soon as I hear back from him I will let you know regardless -- and thank you again for all the help and knowledge @mitchmess! Much appreciated!
Sorry for the late response on validating your solution @mitchmess!
This did end up being the solution although I had a similar setup before we came to the verdict a custom auth was needed, it mostly boiled down to two things as to why this was not working:
The callback URL had a mismatch;
It went temporarily unnoticed that I, personally, didn't have the appropriate permissions set through MSGraph to make the changes I was making
If it weren't for your suggestion and solution, though, it would have been quite some time before I'd of thought to go back to my original setup after the above corrections were made
but this is of paramount importance for my work to get auth delegated through the apps identity rather than the user. I don't have privileges to view things like the client key other than through magic strings provided from our Retool settings.
Which may have also been a misunderstanding on my part!
although I had a similar setup before we came to the verdict a custom auth was needed, it mostly boiled down to two things as to why this was not working: