Menu
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 and have appropriate access to all these RESTful applications in our domain, which may be distributed in a private cloud across many servers. (I understand already that having a single authenticated session is not aligned with a pure RESTful approach, but this is a usability requirement.)
The applications themselves will be written in a variety of programming languages so a language-neutral approach is required. It was suggested to me that we might use OpenID or OAuth or a similar framework to handle the authentication but my understanding is that these are intended for third-party services and not the first-party services that would share data on our internal system. In this case, we might have a central provider service with all the other applications treated as third parties (or relying parties).
Questions:
619
Simply put, OpenID is used for authentication while OAuth is used for authorization. OpenID was created for federated authentication, meaning that it lets a third-party application authenticate users for you using accounts that you already have.
OpenID Connect has become the de facto protocol to authenticate users between applications and external identity providers (IdPs).
OAuth is not authentication. It's an authorization protocol, or, better yet, a delegation protocol. It's for this reason that identity protocols such as OpenID Connect exist and legacy protocols such as SAML use extension grants to link authentication and delegation.
The client uses the access tokens to access the protected resources hosted by the resource server. OAuth 2.0 is directly related to OpenID Connect (OIDC). Since OIDC is an authentication and authorization layer built on top of OAuth 2.0, it isn't backwards compatible with OAuth 1.0.
In OIDC there are three flows where RP can request the authentication of a user from the OP. In the Authorization code flow, first, a code is issued from the OP and then access token and id_token is generated. In authentication request, the response_type should be “code” to gain an authentication type Authorization Code Flow.
OpenID is a protocol used for decentralized authentication. The OpenID specifications can be found here. Authentication is about identity, that is, establishing that the user is, in fact, the person who he or she claims to be.
OAuth is an authorization protocol used to protect resources. The OAuth specifications can be found here. OAuth is a protocol designed to verify the identity of an end-user and grant permissions to a third party. This verification results in a token. The third party can use this token to access resources on the user’s behalf.
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:
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.
72
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
