Custom OAuth provider and access databases

[TomyGrenier]

Hi!

I configured my custom oauth provider in my Filemaker server 19.4.2.20. Every is fine except I can't access database when my external authentication is activated. I only can access to databases through my new custom OAuth provider login page and not with my internal accounts (default FMS login form). Is there a way to do so ? And I can't even not login with my internal admin account. So, I can't configure the databases for using my own provider.

And, is it possible to activate external authentication only on some databases on this server, not all?

Thanks a lot,

Tomy

[Wim Decorte]

Hold down the shift key (or Option on macOS) as you select the file to open. Then log in with a fm account and go to the file options to turn on the option to always show the fm login fields.

what you are seeing is a behavior introduced back in 19.2.

and no: you can not selectively turn on or off the OAuth button per file, it’s there for all files hosted on that server, even if the file has no accounts that are externally authenticated.

look for the feature request on community.claris.com to vote up if you want this to be governed by file.

[TomyGrenier]

Thank you Wim, it really helps me.

And last question : is there a way to get the current user token once connected ?

Thanks again,

Tomy

[Wim Decorte]

None of the tokens used in the FMS-to-IdP OAuth exchange are available in FM; why would you want to use them?

[TomyGrenier]

I have a multiple applications solution and I would like to make some curl request without having to make again a OAuth flow and login. Just call from Insert from URL action  with the token to get user profile info and some data from external API.

 

[TomyGrenier]

@Wim Decorte I wasn't clear. I meant I am looking for profile information of connected user, like his ID.

Edited April 27, 2022 by TomyGrenier

[Wim Decorte]

Not sure I understand the "as its ID" part but if you want profile information about a user, that's just a separate API call to the AD, not part of the authentication flow.

[TomyGrenier]

Ok, I thought that we can get data from OAuth provider through FMS callback URI. I was hoping to get the user id.

Thank you!

[Wim Decorte]

If the user ID that you are after is in the JWT returned by your IdP then you can tell FMS in the Oauth config to use that as the unique user identifier and then you'll get it as the Get(AccountName).

But in general, the authentication flow is just that: to get a yay or nay on letting the user in.  If you need more information about the user, you need to make your own API calls to the IdP.

[TomyGrenier]

Ok, thanks. I thought we get more things from connected user with the authorization profile endpoint that we set in FMS.

[TomyGrenier]

Ok I took the Group Schema part of your article here and try to do the same with Account Schema. 

Let say profile endpoint returns this : 

{
    "id": "ee52921e-5e1a-4949-ad1d-3c12bd79b51f",
    "name": "User Name",
    "email": "[email protected]",
}

Normally, if I change the email value to id in Custom IdP User Account Schema, the Get(AccountName) should return 'ee52921e-5e1a-4949-ad1d-3c12bd79b51f'. Is that correct? Because for now, it still returns the user email.

 

Thanks again,

Tomy

 

 

[Blaine Ott]

Tomy, unfortunately as this white paper, https://fmforums.com/files/file/115-how-to-extend-oauth/, suggests, the response to that function seems to be hardcoded to the email claim.  However, it makes sense to us that it should be related to the Custom IdP User Schema as well.  In our IdP, not every account has an email claim, emails are not necessarily unique and can be easily changed.  We were hopeful this would be updated or at least made an option in 19.5.1, but that doesn't seem to be the case.

 

[Wim Decorte]

If you want to use the full OAuth2 flow instead of Open ID Connect then you'll first have to check whether the IdP supports it.  And you'll have to adjust your scopes because you can't ask for openid if you're not using OIDC.

But in general: yes: with the full OAuth flow you should be able to specify which element from the profile you want to identify the user with.