MFA Grant Type for OAUTH Client

[Johno2518]

Hi,

Just wondering if anyone knows how to enforce the MFA grant type for an OAUTH Client? Currently the grant type requested on the client is password. Theoretically since I setup MFA for all users I assumed it would be implicit (and I should get an error response saying MFA Required according to the spec) on OAUTH clients but it doesn't seem to be the case as it provides me an access token etc.

This is what I currently have enabled.

 

Also one other question, does anyone know what the "log" permission does when enabled on the scope?

 

I feel like there needs to be more in the documentation regarding OAUTH in IPS as I can't seem to find much detail at all.

[Johno2518]

Hmm so looking at login.php under path applications\core\modules\admin\system I found the highlighted bit of code below. This assumes successful authentication/authorisation. After a bit of digging it seems the password grant type is deemed legacy and doesn't support MFA. Shame because I want to avoid a web based login page and redirection in my app when using the authorization code grant type.

What have others used? Architecture is a desktop app talking to a web api which would in turn talk to IPS. There are other microservices running (either as web api or constantly running services) which will talk to the web api that handles authentication/authorisation to validate the token before performing the action requested by the desktop app.

 

 

 

[Marc]

I have flagged this for our developers to take a look at, but I believe 2 factor authentication isnt something that would be used on rest authorisation

[Johno2518]

Hi Marc,

Thanks! It might be good to add device code as a grant type. I could potentially be happy telling a user to jump onto my web site (IPS) to authenticate and type the code shown in my custom app.

If not I may need to force MFA the same way IPS does it currently.

[Johno2518]

While waiting back from the developers - is anyone able to tell me what enabling Log permission does?

Also, I'm now trying to make use of more API endpoints and this one is a little odd. The message for the "me" endpoint shows:

 

However, hovering over secondary groups displays this message:

 

This is confusing because on one hand we can't use API Grant key or client credentials grant type to access the endpoint but in order to retrieve secondary groups we need to? Also, why is secondary groups treated as confidential vs primary group? An end user should be able to access all their profile information so not sure why secondary groups are special.

Interestingly the email address is coming through in my request but not secondary groups. I have added permissions for me/email (which seems counter intuitive since the email is included in profile information).

Can anyone shed light on these odd messages and inconsistencies in responses for that endpoint?

[Johno2518]

@Marc Stridgen have the developers come back to you regarding MFA for an OAUTH Client?

When a user is authenticating from my custom application as an IPS OAUTH Client - I would like to be able to force MFA and call something in IPS to do it (I'm not a PHP guy so reading the IPS code for handling MFA is not so straight forward).

It might be worth adding device code as an available grant type as well.

[Johno2518]

Back on the secondary groups issue, I can see lastVisit and lastPost have the same caveat as secondary groups but that data is being presented when accessing /api/core/me.

Can someone let me know is not providing secondary groups via /api/core/me a bug or is providing lastVisit and lastPost via that same endpoint a bug?

[Johno2518]

Found another bug, I don't see the below options unless I enable Authorization Code grant type. De-selecting that grant type makes the below options disappear even though they are relevant for Resource Owner which I still do have enabled.

 

[Stuart Silvester]

On 12/14/2021 at 11:18 AM, Johno2518 said:

Just wondering if anyone knows how to enforce the MFA grant type for an OAUTH Client? Currently the grant type requested on the client is password. Theoretically since I setup MFA for all users I assumed it would be implicit (and I should get an error response saying MFA Required according to the spec) on OAUTH clients but it doesn't seem to be the case as it provides me an access token etc.

The OAuth 2 spec does not have an MFA grant type, Auth0 however looks like it does have a custom one. We follow the standard OAuth 2.0 specification with our implementation. If you enable MFA in Invision Community, it will prompt the user during the login process.

On 12/14/2021 at 11:18 AM, Johno2518 said:

Also one other question, does anyone know what the "log" permission does when enabled on the scope?

It logs the requests to AdminCP > Rest & OAuth > API logs. It can be useful for debugging and development.

On 12/17/2021 at 6:24 AM, Johno2518 said:

This is confusing because on one hand we can't use API Grant key or client credentials grant type to access the endpoint but in order to retrieve secondary groups we need to? Also, why is secondary groups treated as confidential vs primary group? An end user should be able to access all their profile information so not sure why secondary groups are special.

Secondary groups are a little special, members don't know which secondary groups they belong to and thus they're not made available via the REST API unless using an elevated permissions (API KEY) access.

On 12/17/2021 at 6:24 AM, Johno2518 said:

Interestingly the email address is coming through in my request but not secondary groups. I have added permissions for me/email (which seems counter intuitive since the email is included in profile information).

The /me endpoint is special too, the 'email' information within it is controlled by the 'email' scope that the user accepts when initially logging in. This is the only member object that will contain an email address when using OAuth.

On 12/21/2021 at 7:53 AM, Johno2518 said:

Found another bug, I don't see the below options unless I enable Authorization Code grant type. De-selecting that grant type makes the below options disappear even though they are relevant for Resource Owner which I still do have enabled

This does appear to be a bug, we'll get this addressed.

 

[Johno2518]

40 minutes ago, Stuart Silvester said:

The OAuth 2 spec does not have an MFA grant type, Auth0 however looks like it does have a custom one. We follow the standard OAuth 2.0 specification with our implementation. If you enable MFA in Invision Community, it will prompt the user during the login process.

Ok great, is there an IPS URI and set of parameters that I can call externally (as I'm using Password grant type)?

 

43 minutes ago, Stuart Silvester said:

It logs the requests to AdminCP > Rest & OAuth > API logs. It can be useful for debugging and development.

That's what I thought but I'm only seeing failed requests, no successful attempts. Is this normal?

44 minutes ago, Stuart Silvester said:

The /me endpoint is special too, the 'email' information within it is controlled by the 'email' scope that the user accepts when initially logging in. This is the only member object that will contain an email address when using OAuth.

What about lastVisit and lastPost? They have the same protection (according to the icon/tip) as secondary groups but are coming through in the API response.

 

45 minutes ago, Stuart Silvester said:

This does appear to be a bug, we'll get this addressed.

Great!

[Stuart Silvester]

57 minutes ago, Johno2518 said:

Ok great, is there an IPS URI and set of parameters that I can call externally (as I'm using Password grant type)?

I'm afraid there isn't, you would need to use the Authorization Code flow to use MFA.

57 minutes ago, Johno2518 said:

That's what I thought but I'm only seeing failed requests, no successful attempts. Is this normal?

You should see both, the table has a filter at the top to switch between the types.

58 minutes ago, Johno2518 said:

What about lastVisit and lastPost? They have the same protection (according to the icon/tip) as secondary groups but are coming through in the API response.

These will always be available on the /core/me endpoint, but they're not generally available in the member object anywhere else. -- These can be considered 'sensitive' because they are related to the anonymous sign in functionality, if they were to be available it could leak information about when the user was anonymously active.

[Johno2518]

16 hours ago, Stuart Silvester said:

I'm afraid there isn't, you would need to use the Authorization Code flow to use MFA.

Hmm ok, I might need to switch to another Identity platform as this will provide greater flexibility (and the ability to use the device code grant type if needed).

 

16 hours ago, Stuart Silvester said:

You should see both, the table has a filter at the top to switch between the types.

I've got the All tab selected and only failures (401's) showing.

 

16 hours ago, Stuart Silvester said:

These will always be available on the /core/me endpoint, but they're not generally available in the member object anywhere else. -- These can be considered 'sensitive' because they are related to the anonymous sign in functionality, if they were to be available it could leak information about when the user was anonymously active.

So the /core/me endpoint should have the tooltip removed in that case and left on for /core/members for lastVisit and lastPost properties. As for secondary groups, might be helpful to add another API permission e.g. /core/me/secondarygroups and when enabled, allows all groups to be retrieved for the logged in user when calling /core/me endpoint otherwise the tooltip for secondary groups makes no sense as you'd need a user token to retrieve user ID from /core/me API Endpoint and then an API Key or Client Credentials token to then call /core/members/<id> just to retrieve secondary groups for that user which seems unnecessary.

Edited December 23, 2021 by Johno2518