The OAuth 2.0 Authorization Framework
https://tools.ietf.org/html/rfc6749 (OAuth 2.0)
The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.
Resource Owner Password Credentials
The resource owner password credentials (i.e., username and password) can be used directly as an authorization grant to obtain an access token. The credentials should only be used when there is a high degree of trust between the resource owner and the client (e.g., the client is part of the device operating system or a highly privileged application), and when other authorization grant types are not available (such as an authorization code).
Even though this grant type requires direct client access to the resource owner credentials, the resource owner credentials are used for a single request and are exchanged for an access token. This grant type can eliminate the need for the client to store the resource owner credentials for future use, by exchanging the credentials with a long-lived access token or refresh token.
https://tools.ietf.org/html/rfc6750 (Bearer JWT)
This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport.
What is OpenID Connect?
- OpenID Connect (OIDC) is an authentication layer on top of OAuth 2.0
- Identity + Authentication + OAuth 2.0 = OpenID Connect
- OAuth 2.0 is not an authentication protocol
http://openid.net/connect/faq/
What is OpenID Connect?
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
OpenID Connect allows clients of all types, including Web-based, mobile, and JavaScript clients, to request and receive information about authenticated sessions and end-users. The specification suite is extensible, allowing participants to use optional features such as encryption of identity data, discovery of OpenID Providers, and session management, when it makes sense for them.
See http://openid.net/connect/faq/ for a set of answers to Frequently Asked Questions about OpenID Connect.
How is OpenID Connect different than OpenID 2.0?
OpenID Connect performs many of the same tasks as OpenID 2.0, but does so in a way that is API-friendly, and usable by native and mobile applications. OpenID Connect defines optional mechanisms for robust signing and encryption. Whereas integration of OAuth 1.0a and OpenID 2.0 required an extension, in OpenID Connect, OAuth 2.0 capabilities are integrated with the protocol itself.
OpenID là gì?
OpenID là một tiêu chuẩn mở (open standard) dùng cho việc xác thực người dùng thông qua các nhà cung cấp dịch vụ. OpenID còn được gọi là OpenID provider, ví dụ như Google, Facebook, Twitter... được sử dụng trong việc xác thực.
What is OpenID?
OpenID is an open, decentralized, free framework for user-centric digital identity. OpenID takes advantage of already existing internet technology (URI, HTTP, SSL, Diffie-Hellman) and realizes that people are already creating identities for themselves whether it be at their blog, photostream, profile page, etc. With OpenID you can easily transform one of these existing URIs into an account which can be used at sites which support OpenID logins.
Difference between OpenID and conventional authentification form?
The difference is that the identification will be decentralized to an external site (for example Wordpress, Yahoo, ...). The website will know whether or not the identification is OK and let you login. Conventional website authentication performs a comparison with data held in a private database, so your username and password can be used to login to this website only. With OpenID you can use the same credentials on multiple websites.
How it works?
- You can see the Flow of operation here (image)
- Step-by-step activities here
- Step-by-step activities here (other blog)
Steps
- User connects to OpenID enabled website.
- User enters credential information.
- A POST is made with a BASE64 (website to provider)
- An answer is built (that contains expiration)
- The website redirects the user to the provider to login.
- User enters password and submit.
- Verification is done.
- Login!
OAuth là gì?
OAuth là tiêu chuẩn mở được dùng trong việc trao quyền cho một ứng dụng (client) truy cập các dịch vụ của ứng dụng khác (service provider).
OAuth xuất hiện năm 2006 do Twitter đề xuất để kết hợp với Facebook, Google đưa ra chuẩn chung cho việc Authentication/Authorization
Năm 2008 tổ chức chuyên đưa ra các chuẩn của Internet là IETF đã quyết định hỗ trợ cho chuẩn OAuth
Năm 2010 bản RFC chính thức của OAuth được ra đời
Điểm yếu của OAuth1: Session Fixation (tài khoản facebook của bạn đang được ai đó ung dung sử dụng mà bạn không hề biết...)
Năm 2012: OAuth2 ra đời để khắc phục điểm yếu Session Fixation ở trên
Chú ý rằng OAuth2 cũng được các chuyên gia an ninh mạng cảnh báo về lỗi bảo mật nhưng nó vẫn được sử dụng rất rộng rãi.
Về cơ bản thì OAuth2 không đơn thuần là một protocol, nó là một nền tảng đòi hỏi phải triển khai cả ở server lẫn client.
OAuth viết tắt của cụm từ nào?
OAuth (Open Authorization) is an open standard for token-based authentication and authorization on the Internet.
OAuth 2.0 is not an authentication protocol.
Sự khác nhau giữa OpenID và OAuth?
OpenID is about authentication (ie. proving who you are), OAuth is about authorisation (ie. to grant access to functionality/data/etc.. without having to deal with the original authentication).
OAuth could be used in external partner sites to allow access to protected data without them having to re-authenticate a user.
The blog post "OpenID versus OAuth from the user’s perspective" has a simple comparison of the two from the user's perspective and "OAuth-OpenID: You’re Barking Up the Wrong Tree if you Think They’re the Same Thing" has more information about it.
OAuth là cơ chế xác thực mở, hiện được dùng chủ yếu vào viêc tích hợp ứng dụng vào 1 hệ thống nào đó, thường là social network, các app trên Facebook, Google Plus khi hiện thông báo hỏi bạn cho phép chạy ứng dụng, cấp quyền nọ kia, đó chính là OAuth.
Single Sign On (SSO) là gì?
+ Open Single Sign-On (OpenSSO) hoạt đông dựa trên Token.
+ Central Authenticate Service (CAS) hoạt đông dựa trên Ticket.
SSO là một cơ chế xác thực yêu cầu người dùng đăng nhập vào chỉ một lần với một tài khoản và mật khẩu để truy cập vào nhiều ứng dụng trong 1 phiên làm việc (session).
SSO with CAS or OAuth?
OpenID is not a 'successor' or 'substitute' for CAS, they're different, in intent and in implementation.
CAS centralizes authentication. Use it if you want all your (probably internal) applications to ask users to login to a single server (all applications are configured to point to a single CAS server).
OpenID decentralizes authentication. Use it if you want your application to accept users login to whatever authentication service they want (the user provides the OpenID server address - in fact, the 'username' is the server's URL).
None of the above handle authorization (without extensions and/or customization).
OAuth handles authorization, but it is not a substitute for the traditional 'USER_ROLES table' (user access). It handles authorization for third-parties.
For example, you want your application to integrate with Twitter: a user could allow it to tweet automatically when they update their data or post new content. You want to access some third-party service or resource on behalf of a user, without getting his password (which is obviously unsecure for the user). The application asks Twitter for access, the user authorizes it (through Twitter), and then the app may have access.
So, OAuth is not about Single Sign-On (nor a substitute for the CAS protocol). It is not about youcontrolling what the user can access. It is about letting the user to control how their resources may be accessed by third-parties. Two very different use-cases.
That said, you can implement SSO with OAuth, if you consider the identity of the user as a secured resource. This is what 'Sign up with GitHub' and the likes do, basically. Probably not the original intent of the protocol, but it can be done. If you control the OAuth server, and restrict the apps to only authenticate with it, that's SSO.
No standard way to force logout, though (CAS has this feature).
Application Programming Interface (API) là gì?
Application Programming Interface
OAuth2 with Resource Owner Password Credentials
OAuth 2 with Resource Owner Password Credentials
OWIN OAuth 2.0 Authorization Server
Guide to OAuth2 Grants
https://alexbilbie.com/guide-to-oauth-2-grants/
Google's OpenID Connect
Google's OpenID Connect implementation does indeed not conform to that part of the spec. Google has implemented the OpenID Connect (-like) protocol before the spec was finished and in the mean time some of their RPs have become dependent on that identifier. Modifying it would be a breaking change for those RPs and Google has chosen not to to that, at least for now.
Some OpenID Connect implementations indeed make an exception for Google, others try to generalize this behavior by adding a "https://" prefix to any OP issuer identifier that does not start with it, some don't even check it because they don't implement Discovery related features. Pick whatever you like best.
https://developers.google.com/identity/
https://developers.google.com/identity/protocols/OAuth2
https://developers.google.com/identity/protocols/OpenIDConnect
