Validating acr values (specifically idp) in TokenRequestValidator

[ghost]

On a standard front channel request in AuthorizeRequestValidator there is logic for "check custom acr_values: idp" to ensure that if a client has idp restrictions that the request contains an idp and it is in that restriction list.

All working as expected.

When moving on to implementing the resource owner flow I was expecting the same checks to be made in the TokenRequestValidator however there doesn't appear to be any logic for checking the same acr values.

I have since gone and included that logic in my implementation of IResourceOwnerPasswordValidator however I was wondering if despite respecting acr values and implementing idp restrictions elsewhere, that this was potentially an oversight or was there an intentional reason to not validate that value there.

Cheers,

[brockallen]

When moving on to implementing the resource owner flow I was expecting the same checks to be made in the TokenRequestValidator however there doesn't appear to be any logic for checking the same acr values.

That's hard to do in resource owner flow -- for example, there's not way in resource owner to accept google credentials. Also, resource owner does not travel the UI workflow, and it's not technically OIDC.

[ghost]

That's hard to do in resource owner flow -- for example, there's not way in resource owner to accept google credentials.

Ahhhh... I guess that makes sense. Our implementation exclusively respects internal credential stores, so we always have the ability to handle any idp via the resource owner flow... which wouldn't be the case for something like Google.

In that case can you see any obvious problems with that checking logic existing in the IResourceOwnerPasswordValidator implementation?

[brockallen]

I guess I don't know how you're using the idp acr_value then, as it's designed to assist when using external IdP.

[ghost]

I guess I don't know how you're using the idp acr_value then, as it's designed to assist when using external IdP.

Yeah that's fair. I guess our scenario is a little out of the ordinary (treating internal credential stores as if they were external but still allowing RO flow). Thanks for your comments.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.