Retrieve oAuth Account token from FileMaker login

[sal88]

Hi all

We've been following these guides and are now successfully communicating with our Office365 calendars:

https://dbservices.com/articles/filemaker-outlook-calendar-integration/

https://www.soliantconsulting.com/blog/microsoft-graph-api-filemaker-one/

The app that we have registered in Azure AD is the same as the one we use to authentica/authorise users when they first log in to our FileMaker database.

My question is whether, instead of the user authenticating via the webviewer in order to get the tokens for accessing calendars, they can't use the token that was presumably retrieved/used on the initial logon in to the database.
 

Thanks!

Edited April 9, 2020 by sal88

[Wim Decorte]

Unfortunately not.  FM doesn't use the access token but the id_token for the original authentication and extracts the user and the user's groups from that token.

However given the the user will already be authenticated against the Azure AD because of opening the FM database, the interactive login from my Soliant demo file will be seamless and will not challenge the user again.  Are you finding that not to be the case?

[sal88]

Ah yes sorry Wim that does appear to be the case. I'm not sure how I got confused, possibly because of the account and refresh token expiration occurs every hour (in the db services solution), although as I understand it, just because it expires it doesn't mean that re-authentication is required, just that a new key needs to be retrieved..

So I take it that the initial Azure AD authentication (before opening the FM solution) doesn't necessarily need to via the opening of the database, it could be by simply logging in to the office365 account via web browser?

 

PS thank you for the wonderful demonstration of the Graph API integration on the Soliant blog

Edited April 10, 2020 by sal88

[Wim Decorte]

14 hours ago, sal88 said:

just because it expires it doesn't mean that re-authentication is required, just that a new key needs to be retrieved..

When you first authenticate using OAuth to the Google or Office365 service (or any other, using OAuth) you get an access token and a refresh token.  By default access tokens are valid for one hour (although it can vary and you have some control over it).  That's a hard expiry, one hour after it was issued.  It is not like the Data API where it expires x amount of time after your last activity.

When the token has expired (or even before that) the developer can use the refresh token to get a new access token so that you don't have to take the user back to the login page.  Refresh tokens are valid for a much longer time (Office365 uses 90 days by default I believe).  Usually I don't try to manage those for that amount of time, I destroy both the access and the refresh token when the user quits out of the FM solution so that they'll have to re-authenticate the next time they use the solution.

(Note that all of this applies to the auth flow where you do want the user to be the one authenticating - most services also allow for a server-to-server flow where the user does not need to be involved in).

14 hours ago, sal88 said:

So I take it that the initial Azure AD authentication (before opening the FM solution) doesn't necessarily need to via the opening of the database, it could be by simply logging in to the office365 account via web browser?

Not sure I follow that.

If you are using the same AzureAD and the same 'app' (client id) in AAD for both FM authentication and Office365 API permissions, then yes: it does feel like a bit of a waste to make the user authenticate twice without being able to re-use the original authentication.

If you let people authenticate in their browser first and then have them open FM, they will get into FM by clicking the "microsoft" button without being challenged again because the browser already knows that the auth worked.  So theoretically you could set something up outside of FM to do that initial login into AAD *and* capture the access and refresh token, then let the user authenticate into FM and find a way to pass the tokens into FM so that they can be used for the API.

It would have to take the shape of a microservice that is used as one of the redirect URLs in your AAD app.  So that it can grab the code for the first step of the process and make the API call to get the access and refresh tokens and then write that to the FMS Data API and the FM onOpen script would then need to identify the user and look for that set of tokens wherever the Data API wrote them.