It's been clearly mentioned in the OAuth official website that the OAuth is an authorization protocol instead of, and should not be considered as an authentication protocol. Here I'm confused about this, how can OAuth authorize users if it doesn't authenticate them in the first place.
Another question is: I'm desiging APIs to provide web services for users. If I use OAuth2.0, do I need a login system? If so, how to build this login system?
Authorization (in the context of OAuth) includes authentication as one of its steps, but the OAuth specification (RFC 6749) intentionally avoids discussing how to authenticate a user.
As a result, you can choose any authentication method as you like. For example,
ID & password (most typical)
Fingerprint
Iris recognition
Random table
One-time password
So, your understanding is correct. You need a login system (or whatever which can identify a user) for authentication. The OAuth specification leaves authentication to you.
Related
I am confused about the use of OAuth 2.0 as an Authorization method and OpenID Connect as an Authentication method.
Based on my knowledge OAuth 2.0 is only an Authorization method. In other words, this is the process to request an ACCESS_TOKEN and RECEIVE this ACCESS_TOKEN, like depicted in the image below in yellow ellipse: (simplified)
Before an OAuth 2.0 Client retrieves an ACCESS_TOKEN from an Authorization Server this Server should verify if the User allows it and this is an Authentication Process that OAuth 2.0 does not care about.
When OpenID Connect is included in the mix it allows for an Authentication Method as well, but in my knowledge OpenID Connect just adds a "Claim" in the JWT Token that holds information about user that is using the service, like: email, name and others.
My questions are:
Why not ignore OpenID Connect and just add more "claims" in OAuth
2.0 to get information about users?
Is my description of the flows correct?
OpenID Connect does not merely "add a claim in JWT Token" but:
it introduces a completely new token (id_token) with radically different
semantics than the OAuth 2.0 access_token and a standardized format that is understood by the Client as opposed to the access_token which is opaque to the Client
it "twists" the role of the Client, now becoming the "audience" (or: intended recipient) of a token (i.e. the id_token) whilst the audience of the access_token is still a remote entity (aka. Resource Server) and the Client is only the "presenter" of the latter
The 2nd item is the primary source of confusion between OAuth 2.0 and OpenID Connect.
I don't know if your method will work or not but you're totally free to roll your own authentication. After all, that's what Facebook, GitHub and many others did by customizing oauth2. There ended up being so many oauth2 "authentication" methods that it was never plug and play if you wanted to change your provider. I believe that's why OpenID connect was introduced--a common way of connecting and reasoning about authentication while building on the established oauth2 pattern for authorization. Use OpenID connect or don't...but if you don't you'll be reinventing the wheel.
#sdoxee answers explains thing correctly. But I am adding bit more information for OP's understanding.
These days many identity providers (eg:- Azure AD) issue JWT based access tokens. These JWT access tokens do contain claims about end user as well as JWT related validation details (eg:- Token expiration). Here is the link for Azure AD OAuth 2 success response which highlights access token to be a JWT. Also, see JWT claims to see how they explain the claims. Samples are given below,
family_name : User’s last name or surname. The application can display this value.
given_name : User’s first name. The application can display this value.
One could think of building authentication on claims present in access token, but this is not sticking with protocol. And mostly claims and user information will be implementer specific. Also, by protocol definition, these two tokens (id and access) have two different audiences.
ID token is for client, for validation and for authentication.
Access token is for OAuth 2 protected endpoint.
Again, as #sdoxee highlight, use the correct protocol at correct place. Having claims in access token does not necessarily mean you should use them for authentication.
i'm implementing a REST layer for an existing application. I have my userid and passwords stored in database and i would like to authenticate these credentials while calling my REST services. Note that this is a standalone application.
After investigation, I figured out 2 ways.
Basic implementation with HTTPS - this approach makes sure that
userid and password passed is not tampered by Man in middle attack.
Using Authentication Token(JWT) - user initially passes his userid
and password and server gives back an Authentication token.Once user
have an authentication token that could be used for subsequent
request.
Using OAuth 2.0 - I'm very confused in this approach. After reading the docs and specification, I found that since my application
is standalone, I need to implement Authorization Server, Resource
Server etc.
I'm asked to implement OAuth here, but i'm not convinced that OAuth is required in this scenario. I'm more inclined towards just implementing JWT(tokens)
Is OAuth really mandated in this scenario. What i understand about OAuth is it is used when you already have a service like Facebook/ Google.
Could someone pls confirm if my train of thoughts are correct and if OAuth 2.0 is required in this case?
The primary goal of OAuth 2.0 is to allow users to authenticate to use a client application via a third-party authentication provider (e.g. Google, Facebook, etc.), without exposing their credentials (typically a username/password) to the client.
In your case, if users are only ever going to authenticate to your system using their credentials in your database, then implementing OAuth 2.0 doesn't add any substantial value for you.
The OAuth 2.0 specification does define a "Resource Owner Password Credentials grant", intended for legacy use cases, that would apply to your situation: a user sends credentials, and you return an access token (that could be a JWT, if you like). If it's desirable from a management or marketing perspective, you could implement the Resource Owner Password Credentials grant and legitimately state that your application "conforms to a subset of OAuth2, as defined by RFC6749".
OAuth terminology has been bothering me a long time now. Is OAuth Authorization as some would suggest or is it Authentication?
Correct me if I'm wrong but I have always read Authorization as being the act of allowing someone access to a resource yet OAuth doesn't seem to have any implementation that actually allows access to users to a given resource. All OAuth implementations talk about is providing a user a token (signed and sometimes encrypted). This token is then passed with every call to a back-end service endpoint where it is checked for validity, again not an OAuth concern.
Is OAuth Authentication (every article says it isn't) which I take it requires a user to provide credentials which in turn proves a user should/shouldn't have access?
So it seems that OAuth is not Authorization NOR Authentication since these have to be performed by other processes. So what the heck is it? Is it a process for communicating a token? Is it fluff word that really has no specific meaning?
It's hard to ask a question about this subject without sounding enigmatic and superstitious (ghosts and goblins) so I expect that answering this question won't be a simple thing either. Enter at your own risk.
OAuth is a specification for authorization
OAuth 2.0 is a specification for authorization, but NOT for authentication. RFC 6749, 3.1. Authorization Endpoint explicitly says as follows:
The authorization endpoint is used to interact with the resource owner
and obtain an authorization grant. The authorization server MUST first
verify the identity of the resource owner. The way in which the
authorization server authenticates the resource owner (e.g., username
and password login, session cookies) is beyond the scope of this
specification.
OAuth authentication?
Authentication deals information about "who one is". Authorization deals information about "who grants what permissions to whom". Authorization flow contains authentication as its first step. It is the reason people are often confused.
There are many libraries and services that use OAuth 2.0 for authentication. It is often called "social login" and It makes people more confused. If you see "OAuth authentication" (not "OAuth authorization"), it is a solution using OAuth for authentication.
OpenID Connect
OpenID 1.0 and OpenID 2.0 are old specifications for authentication. Those who made the specifications expected people to use OpenID for authentication. However, some people began to use OAuth 2.0 for authentication (not for authorization) and OAuth authentication has prevailed rapidly.
From a viewpoint of OpenID guys, authentication based on OAuth was not secure enough, but they had to admit that people preferred OAuth authentication. As a result, OpenID guys decided to define a new specification, OpenID Connect, on top of OAuth 2.0.
Yes, this has made people much more confused.
One-sentence definitions of OAuth 2.0 and OpenID Connect
OAuth 2.0 is a framework where a user of a service can allow a third-party application to access his/her data hosted in the service without revealing his/her credentials (ID & password) to the application.
OpenID Connect is a framework on top of OAuth 2.0 where a third-party application can obtain a user's identity information which is managed by a service.
(Sorry, these definitions are excerpts from the overview page of my company)
Definitions from a viewpoint of implementors
Authentication is a process to determine the subject (= unique identifier) of an end-user. There are many ways to determine the subject. ID & password, fingerprints, iris recognition, etc.
Authorization is a process to associate the subject with the requested permissions and the client application that requested the permissions. An access token represents the association.
See Also
Full-Scratch Implementor of OAuth and OpenID Connect Talks About Findings
Diagrams And Movies Of All The OAuth 2.0 Flows
Diagrams of All The OpenID Connect Flows
The Simplest Guide To OAuth 2.0
OAuth is an authorization protocol. It is not designed for authentication. Yes, there is a step in the OAuth process where the identity server authenticates a resource owner. The way it happens does not belong to the OAuth protocol. That is why OAuth does not concern itself about authentication.
OAuth performs authorization by giving an access token to a third party (service provider) and that party will be able to authorize access to the resource by presenting the token.
Let's say there is a requirement that a service provider wants to access resources (protected by an identity server) on behalf of the resource owner. So the resource owner will first authenticate and then will grant permission for the service provider to access specific resource. Then the identity server will issue an access token for service provider. Later the service provider can access the resource with that token.
Here, OAuth does not care about who is carrying the access token or trying to access the resources. It validates the access token, and lets the third party access the resources.
I'm suppose to build a web application and a mobile application (for iOS) that share the same database. Currently I'm thiking about having a RESTful API and have both applications (web and iOS) comunicate with the API to access data. My problem is the authentication method that I should use. I've been researching about OAuth2.0 but that's not quite the thing I want because I don't want the user to have to authorize the connection as it happens when you log in somewhere using facebook or google+. I just want to make the login with a username and password and then stay logged in. And this for both the apps (web and iOS).
I'm using Node.JS and MongoDB to build the API.
I'm trying to do things "the correct way" because this is suppose to be the final project for my masters.
Can you guys give me some lights in how I can achieve this?
Use OAuth 2.0 so you have an extensible standard and token-based authentication which enables users to revoke authentication tickets, e.g. if their phone was stolen.
OAuth 2.0 supports various grant types. Those that you from facebook and twitter logins can be summarized as '3-legged oauth', but there's also two grant types for 2-legged OAuth, especially the resource owner password credentials grant (section 4.3 at the end of the page) which will simply exchange username and password for an authentication token. There's no need to implement 3-legged oauth if you don't want to.
I'd suggest to use database-stored tokens over crypto-based self-validating tokens for most use cases. The possibility to revoke individual grants, or all grants of specific client applications is super helpful in practice. It also shortens tokens a lot and reduces the risk of a catastrophic security leak because of a flaw in the implementation. Make sure the token itself is crypto-strong random and use a simple crypto-wrapper around the actual token value to enable cheap identification of (badly) faked tokens.
Something like Passport (no, not the whisky, but the middleware) could be a good thing to test
It allows to choose among many different authentication methods in an easy and transparent way
We're building a new app that requires access to specific customer data, and OAuth appears to be absolutely perfect for our requirements - long-lived access tokens, ability to grant access to specific resources or scopes, and so on. We are not looking for 'log in with Facebook' type capabilities here; we want to expose a single, specific OAuth authentication server based on our existing customer login database, and allow web and native apps to authenticate users via this endpoint.
I've been looking at the DotNetOpenAuth code samples, and it appears that all of the OAuth 2 examples use OpenID to perform the initial authentication and then use OAuth to actually authorise access to resources.
My understanding is that you can use a 'no-op authorisation' to perform the initial authentication, allowing you to use OAuth2 for the whole process; since we don't want to support federated authentication, OpenID doesn't actually offer anything, and so I'd rather stick to a single protocol for simplicity if possible.
Is there a good example anywhere of a pure OAuth2 authentication server built using .NET? Have I misunderstood the example code supplied with DotNetOpenAuth? Or is OpenID still required for the initial authentication phase?
There's no coupled relation between OAuth2.0 and OpenId.
You can implement your custom login strategy in your OAuth2.0 implementation.
Since you gonna be the "Resource Owner"(as far as I understood your application owns the user base), you can simply replace in the DNOA authorization server sample the openid login with the standard asp.net login.
OAuth2.0 protocol simply needs to verify a user identity in order to emit an access token: how that identity will be verified is totally up to you.