I was just looking at Spring Authorization Server and noticed that it mentions OAuth 2.1.
What are the differences between OAuth 2.0 and 2.1?
The OAuth 2.1 specification is currently in draft state. Because of that it currently not clear what will be the final differences.
See current draft: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-05
Excerpt from the current draft:
This draft consolidates the functionality in OAuth 2.0 [RFC6749],
OAuth 2.0 for Native Apps ([RFC8252]), Proof Key for Code Exchange
([RFC7636]), OAuth 2.0 for Browser-Based Apps
([I-D.ietf-oauth-browser-based-apps]), OAuth Security Best Current
Practice ([I-D.ietf-oauth-security-topics]), and Bearer Token Usage
([RFC6750]).
Where a later draft updates or obsoletes functionality found in the
original [RFC6749], that functionality in this draft is updated with
the normative changes described in a later draft, or removed
entirely.
A non-normative list of changes from OAuth 2.0 is listed below:
The authorization code grant is extended with the functionality
from PKCE ([RFC7636]) such that the default method of using the
authorization code grant according to this specification requires
the addition of the PKCE parameters
Redirect URIs must be compared using exact string matching as per
Section 4.1.3 of [I-D.ietf-oauth-security-topics]
The Implicit grant (response_type=token) is omitted from this
specification as per Section 2.1.2 of
[I-D.ietf-oauth-security-topics]
The Resource Owner Password Credentials grant is omitted from this
specification as per Section 2.4 of
[I-D.ietf-oauth-security-topics]
Bearer token usage omits the use of bearer tokens in the query
string of URIs as per Section 4.3.2 of
[I-D.ietf-oauth-security-topics]
Refresh tokens for public clients must either be sender-
constrained or one-time use as per Section 4.12.2 of
[I-D.ietf-oauth-security-topics]
See: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-05#section-10
Related
We have use case where we need show user credential params such as username and password and based on user name value and password validation on backend side we have to render swagger APIs.
Not able to figure out how i can render swagger APIs based on result of authentication result.
Any pointer will be highly appreciated.
You didn't mention which version of swagger you are using, but it looks like there is support for protecting endpoints via some kind of authentication using Swagger 2.0 and 3.0.
From the 2.0 docs:
Swagger 2.0 lets you define the following authentication types for an API:
Basic authentication
API key (as a header or a query string parameter)
OAuth 2 common flows (authorization code, implicit, resource owner password credentials, client credentials)
From the 3.0 docs:
OpenAPI uses the term security scheme for authentication and authorization schemes. OpenAPI 3.0 lets you describe APIs protected using the following security schemes:
HTTP authentication schemes (they use the Authorization header):
Basic
Bearer
other HTTP schemes as defined by RFC 7235 and HTTP Authentication Scheme Registry
API keys in headers, query string or cookies
Cookie authentication
OAuth 2
OpenID Connect Discovery
Each of those sets of documents has links to examples and further documentation.
I am very confused about the difference between oauth2 tokens and json web tokens.
I have searched about these technologies and the result is ;
Open Id is a protocol and It uses JSON Web tokens to ensure the requests are coming from a trusted user.
A Json web token contains a few user information ( claims ) as encrypted with a private key of sts.
Oauth2 is a framework and we can manage the login operations between our users , clients and resources and third-party applications.
Identity Framework 4 is an Open Id connect implementations .net MVC library. The library has written with oauth2 specs and it implements Open Id.
This is the point I didn't understand. The Oauth2 framework already has its token implementation.
Where is the place of JSON web tokens in this scenario?
For example, we have a simple web application and a server which implements identity server 4.
When a user requested a page from web application user will be redirected to our identity server to login operation.
After successful login Identity server adds a cookie to our response and these cookıe contains a token.
We wıll use that token when requests the other secure resources .
These steps are clear for me. Where is the Jason Web token in this schenio ?
How can I use JSON web tokens in my client app?
Where can I reach my user claims?
The reason for JWT is given in the specs of OAuth2
Since OAuth 2.0 does not define a protocol for the resource server to
learn meta-information about a token that it has received from an
authorization server, several different approaches have been
developed to bridge this gap. These include using structured token
formats such as JWT [RFC7519] or proprietary inter-service
communication mechanisms (such as shared databases and protected
enterprise service buses) that convey token information.
Being an open-standard JWT has been largely adopted in security-related technology and protocols. It defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed
Let's explain some concepts of this definition further.
Compact: Because of their smaller size, JWTs can be sent through a URL, POST parameter, or inside an HTTP header. Additionally, the smaller size means transmission is fast.
Self-contained: The payload contains all the required information about the user, avoiding the need to query the database more than once.
There are a lot of sites explaining these things as well as numerous technology providers.
https://jwt.io/introduction/ for providing tutorials and free e-book
https://oauth.net/2/ for in-depth stuff
https://openid.net/connect/ for the new kid on the block
To answer your IdentityServer related questions. Authentication & authorization related information are usually encoded
access token
identity token
The application-specific information/payload in these tokens is encoded using JWT. JWT is mostly transparent to application developers if good libraries are provided - as is the case for IdentityServer. You will find answers to your questions in the excellent documentation for IdentityServer. How to extract user claims is covered as well. The project provides numerous client examples that cover typical AuthX setups out there. It takes time and commitment to get through it.
JSON Web Token (JWT) (RFC 7519) itself is independent of OAuth 2.0 and OpenID Connect. You can use JWT wherever you like.
OAuth 2.0 is a specification as to how to request and issue access tokens. The specification does not say anything about how access tokens should be represented. Therefore, access tokens may be random strings or may be JWTs. Some authorization server implementations generate random strings and issue them as access tokens, and other implementations generate JWTs and issue them as access tokens. See “7. Access Token” in “Full-Scratch Implementor of OAuth and OpenID Connect Talks About Findings” for further discussion.
OpenID Connect is a specification as to how to request and issue ID tokens. The specification says an ID token is a kind of JWT. In addition, JWT is used in other places in the specification. Responses from UserInfo Endpoint are either plain JSON or JWT. Request Objects are JWT.
In normal cases, a server which supports OpenID Connect can issue both ID tokens (which are JWTs) and access tokens (which are either random strings or JWTs). This may be making you confused. Reading the following articles may be of help.
Diagrams of All The OpenID Connect Flows
Diagrams And Movies Of All The OAuth 2.0 Flows
From what I can tell, the OAuth 2.0 specification is extremely vague in terms of what form an access token should take:
The token may denote an identifier used to retrieve the authorization
information or may self-contain the authorization information in a verifiable manner (i.e., a token string consisting of some data and a signature). Additional authentication credentials, which are beyond the scope of this specification, may be required in order for the client to use a token.
The access token provides an abstraction layer, replacing different authorization constructs (e.g., username and password) with a single token understood by the resource server. This abstraction enables issuing access tokens more restrictive than the authorization grant used to obtain them, as well as removing the resource server's need to understand a wide range of authentication methods.
Access tokens can have different formats, structures, and methods of utilization (e.g., cryptographic properties) based on the resource server security requirements. Access token attributes and the methods used to access protected resources are beyond the scope of this specification and are defined by companion specifications such as RFC6750.
(emphasis added)
The linked RFC6750 doesn't offer much further specificity. There is an example HTTP response body that shows:
{
"access_token":"mF_9.B5f-4.1JqM",
"token_type":"Bearer",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
}
This seems to indicate that the access_token can be opaque ASCII text such as an encoded JSON Web Token (JWT)
From my perspective, it seems like JWT-as-access_token has some desirable properties:
It's a known specification, with fairly wide adoption and client libraries available in many languages.
It allows for easy signing and verification using vetted cryptographic libraries.
Because it can be decoded to JSON, it would allow us to include metadata and information about the token within the token itself.
My questions are: First, is it permissible for the access token to be a JWT? Second, if it is permissible according to the spec, are there any additional considerations that would make using a JWT as an access token a bad idea?
A1: Using a JWT as an access token is certainly permissible by spec exactly because the spec does not restrict its format.
A2: The idea behind using a JWT as an access token is that it can then be self-contained so that the target can verify the access token and use the associated content without having to go back to the Authorization Server. That is a great property but makes revocation harder. So if your system requires a capability for immediate revocation of access, a JWT is probably not the right choice for an access token (though you can get pretty far by reducing the lifetime of the JWT).
As long as the Authorization Server and the Resource Server agree on what the access token means, it doesn't matter what their content is. So the only reason you could have a problem would be if you were using different libraries or frameworks when implementing those two servers.
Currently the OAuth Working Group is working on a JWT profile for OAuth 2.0 access tokens: JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
I was looking for some information on the Internet about that and ended up on the RFC for The Oauth 1.0 Protocol: https://www.rfc-editor.org/rfc/rfc5849
You can read "Obsoleted by: 6749" at the top of it and if you follow that link, you end up on the The OAuth 2.0 Authorization Framework RFC.
Based on that, can I safely infer that OAuth 1.0 has been deprecated in favour of OAuth 2.0?
Thanks.
Yes and No.
IETF has published a new version of OAuth 2 obsoleting OAuth 1.x and it strongly recommends the new Auth providers switch to OAuth2.
There is a revision to OAuth 1.0a which fixes many of the security flaws found in 1.0 and is widely considered to be the most secure OAuth version yet.
OAuth2 is a completely new protocol and is not backwards compatible with OAuth 1.x. The major differences with respect to OAuth 1 are listed in this thread.
However, not everyone is as happy with the new standard. Eran Hammer-Lahav, the lead author and editor of OAuth specifications, resigned from the committee citing reasons in this blog post.
Homakov, who rose to fame with his exploit on Github, has not so nice things to say about OAuth 2.
So yes, OAuth 2 has officially replaced OAuth 1.x, but there are conflicting opinions on the net on whether one should use OAuth2 or stick with OAuth 1.0a.
Yes )
The most of companies use 2.0 - for example google:
Important: OAuth 1.0 has been officially deprecated as of April 20,
2012. It will continue to work as per our deprecation policy, but we encourage you to migrate to OAuth 2.0 as soon as possible.
but there are some using 1.0 or 1.0a as you can see wiki: OAuth in the chapter List of OAuth service providers
There is also an official information that 1.0 is deprecated RFC 6749: The OAuth 2.0 Authorization Framework
.. This specification replaces and obsoletes the OAuth 1.0
protocol described in RFC 5849.
And RFC 5849 is The OAuth 1.0 Protocol
The direct answer to your question is yes. From the OAuth 2.0 spec:
it is the intention of this specification that new implementations support OAuth 2.0 as specified in this document and that OAuth 1.0 is used only to support existing deployments.
Although I prefer OAuth 2.0, and have implemented a 2.0 authorization server and contributed to the spec, I'm not able to say that one is better than the other. I do believe that 2.0 is easier to work with.
As a useful protocol, OAuth 1.0 is not obsolete or irrelevant. As of version 1.0a (RFC 5849 is 1.0a), I know of no vulnerabilities that make it less secure than 2.0, and in fact it is arguably more secure by default. 1.0 is just as capable of handling most use cases.
OAuth 2.0 is incompatible with OAuth 1.0; it is a completely new protocol. The design decisions that drove development of 2.0 were not rooted in flaws of 1.0, per se, but rather 2.0 was borne out of a desire to make OAuth simpler to implement, and more elegant for use cases that were hard for 1.0 (such as native apps).
Some differences which may be worth noting:
2.0 relies on the security provided by TLS encrypted connections. 1.0 does not require TLS, and as a result the protocol is more complicated because it has to include its own defenses against man-in-the-middle attacks. For example, 1.0 relies on signed requests to access protected resources, whereas 2.0 offers a much simpler Bearer access token type.
2.0 splits the OAuth server into two conceptual roles: (1) authorization server and (2) resource server. This separation of concerns fits naturally with enterprises where authorization concerns are spread across many servers responsible for different types of resources.
2.0 distinguishes between confidential and public clients. Public clients are those that run on user devices, and therefore they cannot reliably keep secrets (hard-coded, embedded credentials). Distinguishing between confidential and public clients makes it easier to make secure implementation decisions that suit the needs of client application developers.
2.0 introduces multiple authorization grant types. Each grant type has its own protocol flow, and these protocol flows make OAuth 2.0 adaptable for multiple use cases and client types.
2.0 makes a great effort to be extensible. Section 8 of the spec makes provisions for defining new access token types, grant types, and protocol parameters. For example, in addition to bearer tokens, work is going into MAC tokens and JWT bearer tokens.
This is subjective, but one might say that OAuth 2.0 tries to be flexible for many use cases, where OAuth 1.0 required developers to fit their use cases into a more rigid framework.
I don't really think that you can say that OAuth 1.0 has been deprecated in favour of OAuth 2.0. You can still work with the 1.0 if it suits on your demands.
The 2.0 is better for large scale like Twitter did the deprecation and changed it's API from 1 to 1.1, so to make use of the new OAuth, but that has to do with twitter.
In another case maybe 1.0. is still working perfect, so no need to upgrade.
OAuth 2.0. has to do more like with public encryption, public key. And not private, not great news as that method is known years now.
So that's way there are still be different opinions about if is good or bad.
Here Oauth2.0 and the road to hell, and here OAuth 2.0'bad' i think you can find more interesting and detailed information of what you want.
i have several questions...
Does yahoo and microsoft api support
oAuth 2.0?
If yes then what are the main
security measures those should be
taken care of while shifting from
oAuth 1.0 to oAuth 2.0.
Google API supports oAuth 2.0. But
they have still marked it as an
experimental. Is it good to start
shifting even though it is
experimental?
I see while registering an
application on google (for oAuth
2.0), they ask for callback url. If a single application uses a
condition dependent callback url
such as -
if($myVar == NULL) $callbackUrl = 'http://www.mydomain.com/test.php?m=f¶ms=null'
else $callbackUrl = 'http://www.mydomain.com/test.php?m=x¶ms=1'
How can i implement above when the callback url is already specified? The above conditional mainly handles fallback model of an application or if browser supports java then java based model of an application. Kindly suggest
May i know how many of email
providing websites and social
networks supports oAuth 2.0?
Yahoo does not support OAuth2 yet, only Oauth 1.
Microsoft does support OAuth2. http://msdn.microsoft.com/en-us/library/hh243647.aspx
Oauth 2 is simpler since it uses SSL (HTTPS) to provide transport security, so the signatures and token-secrets are not needed. When you switch you will need to re-implement your OAuth flow. I can't think of any specific security measures specifically applicable to upgrading from OAuth1 to OAuth2, but the spec details some security considerations in section 10 (The parts applicable to clients are 10.3, 10.4, 10.5, 10.6, 10.8 and 10.9).
The OAuth2 specification is still not finalized, and may change. You could begin to implement your OAuth2 flow with Google, but bear in mind that it is possible that names or requirements of parameters, endpoints etc. could change and your application will break / you will need to make changes in future. [Experimental Features] could change (or even be removed) at any time. It is probably a bad idea to use experimental (or beta) software in a critical production environment.
Also, not all Google services support OAuth2 at the moment. eg. If you want to use OAuth for IMAP access to Gmail you will have to use OAuth1 for now.
In the API Console, you can specify multiple callback URLs for your OAuth2 application, one per line. An alternative would be to store your 'm' and 'params' parameters in a browser session / cookie and do the redirect to the correct page once authorization is complete.
Support (some revision of) OAuth2: Facebook, Microsoft/Live, Google (with exceptions described above), Foursquare, GitHub, Gowalla, GeoLoqi, Salesforce.
Support OAuth1 Only: Yahoo, Flickr, Twitter.
Source.