FusionAuth
    • Home
    • Categories
    • Recent
    • Popular
    • Pricing
    • Contact us
    • Docs
    • Login

    Authorization lambda?

    Scheduled Pinned Locked Moved
    General Discussion
    2
    3
    3.6k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M
      mgetka Power User
      last edited by

      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/token requests. Each intercepted request is passed to FA's token endpoint 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_tokens that might have been created and respond with access_denied OAuth2 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.

      1 Reply Last reply Reply Quote 0
      • danD
        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

        --
        FusionAuth - Auth for devs, built by devs.
        https://fusionauth.io

        1 Reply Last reply Reply Quote 0
        • M
          mgetka Power User
          last edited by

          Ok, I've created a feature request.

          1 Reply Last reply Reply Quote 1
          • First post
            Last post