How to use OpenID or OAuth for internal first-party authentication?

前端 未结 2 858
广开言路
广开言路 2021-01-31 10:24

I am working on an internal authentication system for users of a set of of RESTful web applications. Our intention is that a user should be able to sign-on once via a web form

2条回答
  •  暖寄归人
    2021-01-31 10:57

    You do not need OAuth for SSO services.

    The primary use/advantage of OAuth is, as you know already, granting access to a 3rd party app to access/use your resource in a controlled manner.

    Rather than having an authentication/authorization server that you would need for OAuth, why not use a single log in service across all your APIs. An OAuth access token is totally different from what you need.

    As far as I understand, what you can have is something like OAuth in a way that your server vends out tokens to the app. (I'm assuming that it's a totally internal system, so tokens cannot be misused).

    So basically what I'm proposing is:

    1. When an app tries to access the first API it's redirected to a web-form.
    2. The user enters credentials and is taken to the DB for verification. Let there be a service that generates a token for the user/app
    3. Next API access request would be made with that token - the token uniquely identifies the app
    4. Depending on the level of security you need you can sign some text using HMAC and send it as token, or if its totally internal just generate a unique identifier for the app/user and send it to other API
    5. On receiving the token, each service first calls the main server with the token and internally fetches the corresponding customer/user ID and performs the required function.

    In short separate the login + token generation + token verification into a different module. All APIs should use this module for login/token verification.

    What I have proposed here works like OAuth but all security aspects have been stripped down since you want to use it in a private cloud.

提交回复
热议问题