Accessing the authentication code when using Integrated Authentication

When logging in via the Microsoft Login, Microsoft returns a code that may be used later to obtain a Graph API token.  Is there any way to access that code when using Integrated Authentication?

Hi Dave,

Long time since we last spoke.

The token is usually present on the URL of the redirect back to the OutSystems app, I should say "a" token.

Not sure if it can be used for the purpose you described or if you need to a call to some Microsoft api to get a specific one.


Thanks for responding, Rui.  Yes, it HAS been a long time.

I guess the question I need to answer now is whether OUR app receives the code or whether, when using Integrated Authentication, OutSystems receives the code and may or may not pass it along to us.

The process is documented by Microsoft here:

and, as I noted above, what we are trying to accomplish is to use the code returned by Microsoft in an authentication request to request a token which can be used for later Graph API requests.

Hi Dave,

If it authenticates it must.

Now, I'm not sure how your application is authenticating, but the final stage of the authentication process is obtaining a token from the Microsoft API.

In the documentation link you shares it is step 3. Get a Token

From there it should be a matter of consuming the REST end point to obtain the Graph API token, as described on step 4.

How does your application uses the Microsoft authentication? Are you using pure oAuth2? Any forge component?


Presently, we are using the MicrosoftLoginConnector Forge component to perform authentication and using the Forge Graph API component to perform other functions.  The MicrosoftLoginConnector provides the code and the token.  To the best of my knowledge it's all OAuth2.  We believe that using built-in OutSystems functionality is a sounder approach, more resilient to change, and would prefer to use it without discarding what we have developed using the Graph API component.  

That's why I am looking for an approach that uses the built-in external authentication.

Hi Dave,

I get it now.

However the OutSystems built in authentication supports the traditional internal (user/password), Active Directory/LDAP and SAML based (Azure, Okta, Ping 1, etc)

But the supported Azure is SAML based, not oAuth2.

You can check the end user authentication here.

Often SAML is used to just authenticate the user, see his permissions and groups and in azure case bring active directory user information to web applications.

oAuth is more common to interact with applications (e.g. mail, calendar, etc.) on behalf of a user, meaning your web app doing stuff on a calendar of an Azure user.

This to say that since I don't know the use case please consider the pros and cons of such a change.



The use case is pretty ambitious.  In essence we have re-created Outlook INSIDE of the OutSystems app we've built for the customer.  Between that and the WOPI integration of the cloud file storage being used, users can read or send mail. view and edit Office documents, or store their mail in cloud file storage without ever leaving the app.