I'm starting this thread to share my thoughts on an authorization aspect of the service. I guess I won't be wrong in saying that FusionAuth is more about authentication than authorization. On the GH issues regularly arise threads such as:
- prevent user login if the user has not verified his email,
- prevent user login if he has no registration in the application,
- prevent user login if he is not in specific group,
- prevent user login if XYZ...
For each of such issues, the only, and indeed valid response is to perform authorization in the client app, since the token will be returned always if the user credentials are valid. This approach is problematic if FA is used to authorize access to some third party software that we cannot or don't want to alter. For the case of in-house developed software it is problematic since we have to maintain very similar blocks of authorization code in multiple applications.
Attempt on covering all the usable authorization rules cases from the UI would most probably result in checkboxes nightmare, but why not lambda? I suppose that such lambda, with access to the API and possibility to forbid access would cover most, if not all cases. Activation of the lambda on per application basis seems reasonable.
I've developed, let's name it - a prototype, of such functionality for my installation. It is a proxy service, that intercepts
/oauth2/tokenrequests. Each intercepted request is passed to FA's
tokenendpoint like in classic reverse proxy. If the authentication failed, the FA's response is passed back to the original client. If the authentication succeeded, our custom authorization rules are evaluated. If our rules are fulfilled, FA's response is passed to the original client, otherwise, we revoke all
refresh_tokensthat might have been created and respond with
access_deniedOAuth2 error code. This is not ideal - it would be better if no refresh token has been created if custom rules fail. Also, if something goes wrong on rules evaluation, dangling refresh tokens may remain in the user account context. But it works, there is one central service managing authorization rules.
So, to sum it up - personally, I would be pleased if I could move the authorization rules into such an lambda, and have all auth&auth aspects covered by FusionAuth. Seeing the flexibility of such solution, I suppose it would cover needs of other community members as well. I didn't wanted to share this as a feature request per se, since I don't actually need it at the moment - I have my workaround. I just wanted to share my insights and maybe start a discussion that may result in more concrete feature draft.
dan last edited by
This seems like a great feature request. Please consider filing one: https://github.com/fusionauth/fusionauth-issues/issues
Related, but not the same: https://github.com/FusionAuth/fusionauth-issues/issues/952
Ok, I've created a feature request.