I'm building a service provider application where users are supposed to be able to share their data with a third party application using OAuth2 and OpenID Connect.
The standard OAuth2 consent flow authorize scopes (which attributes / roles to share).
However, since attributes could consist of multiple values, we would also like to allow the user to select which value/s to share.
So my question is, should I replace the whole OAuth2 consent flow with a custom one where OAuth2 scopes are more or less replaced with explicit attribute key/value pairs?
It feels a bit weird to remove such a core component of OAuth2 as scopes, what do you think? Any other suggestions?
I'm currently trying out spring authorization server for customizing the consent flow (since Keycloak that we're currently using doesn't seem to be that flexible with the consent logic).
I think that replacing the standard consent flow in spring authorization server would require rewrites of both OAuth2AuthorizationConsentService, OAuth2AuthorizationConsentAuthenticationProvider as well as all the OAuth2...AuthenticationProvider classes that are used for authentication in order to forward consent to the new consent flow.
Check out the official custom consent sample! This sample demonstrates a custom consent screen without replacing the built-in components for handling submission of the consent screen and saving user consent in the OAuth2AuthorizationConsentService.
In particular, these lines configure the consent page, and this controller endpoint implements the logic for building a custom consent screen, which can be whatever you need for your application.
If you are wanting to customize what is mapped from the consent screen to the saved authorization, you would customize the OAuth2 Authorization Endpoint with an authorizationRequestConverter(). Scopes are simply stored as "authorities", so you can instead (or in addition) store anything you want.
To customize the access token (JWT) that is produced as a result of this consent and authorization, provide a OAuth2TokenCustomizer<JwtEncodingContext> as in the example OAuth2TokenCustomizer from the reference documentation.
What you are describing is the exact purpose of scope: contain user consent on what data (attributes names) a specific client can access on their behalf. Usually, to ease user selection and software maintenance, the attributes granularity in scope selection is not the same as internal data model (for instance a contact scope could represent phone, country, city, zipcode and street columns in database)
As roles, groups, permissions or whatever should be mapped to Spring authorities are not specified by Oauth2 nor OpenID, authorization-servers use private claims to store this data (and usually not scope). If you are used to Keycloak, you should have noticed that roles are put by default in realm_access.roles and resource_access.{client-id}.roles. Other authorization-servers will use other private claim(s).
Simply put, roles (or groups or permissions or whatever you want to call it) define what a specific user can do in the system when scope should contain which resources a specific client is allowed to access on behalf of that user.
Thought I'd add some use-case based notes on the parties involved, and how consent is meant to work.
CLIENT
The client app simply redirects with a scope parameter. It is possible to send a claims parameter but that is rarely used. A scope might be profile and be composed of name and date of birth claims.
AUTHORIZATION SERVER
This presents the requested information in a consent screen. The most flexible way to do this is to present the claims, eg as checkboxes. Some claims, eg name, might be marked as required and use a disabled checkbox. Others, eg date of birth, can be optional. The user might deselect the latter claim and it would then not be included in tokens issued.
CUSTOMIZING CONSENT
Ideally no customization should be needed to achieve the above, which should work out of the box. This may not be the case for Spring though. It is valid to customize consent though. An interesting case where this is done is in Open Banking, where a user can consent to payment of a runtime amount of money:
I consent to pay company X £100 for product Y from account Z
I'm in the process of converting an internal C# API that uses a legacy SOBO integration to one that uses OAuth 2.0 as required by DocuSign. The legacy application makes all requests to DocuSign using DocuSign credentials of an application user (a non-person) and injects SOBO data (email address) in the appropriate header when we need to generate an embedded sending URI and have it appear that the envelope was sent by a real person without using their credentials.
I have successfully converted another (non-SOBO) internal API using JWT grant, but I do not know how replicate the SOBO dependent workflow. Have read Matt King's article "From the Trenches: OAuth 2.0 and the new SOBO", but still a bit confused. I know how to extract userId from email address as mentioned in the article, but not sure what do with it. Similar to my legacy application, I am using a application user to get consent and ask for JWT token without prompting internal users for their consent. Is this still possible using OAuth 2.0?
Happy to help here. Once you've retrieved the user's apiUserName / userId you'll want to add it into the JWT assertion's sub line.
When you go to generate the token, if consent has not been provided by or for the user, our system will send back an error of "Consent_Required." See https://www.docusign.com/blog/developers/oauth-jwt-granting-consent for different methods of granting consent.
For individual consent, the user needs to go to a specific URL containing your clientId, redirectUri, and some additional scopes. If they hadn't previously consented to the scopes in your OAuth request they will be prompted to do this once. You can confirm consent has been applied by having them visit the same link afterwards, which will send them directly to your redirectUri.
Domain consent works a little differently -- you need to have an organization, a claimed domain, and the users you're providing consent on behalf of need to have an email address that is part of that claimed domain.
Happy to connect and walk you through it -- if you can open a ticket at support.docusign.com and in the details request they reach out to me I should be able to have the case transferred and work with you from there.
Regards,
Matt King
In the Authentication Request, if users previously gave consent to some client (for a specific list of scopes) and because they might be prompted for the same authorization multiple times. ¿Could be acceptable to skip it?. ¿Works on both code and implicit flows?. ¿How much time remember the consent?.
I'm a little bit confused about the way to implement this. The Oauth2 draft say:
... and obtains an authorization decision
(by asking the resource owner or by
establishing approval via other means).
And OpenID draft say:
... this MAY be done through an interactive dialogue with the End-User
that makes it clear what is being consented to or by establishing
consent via conditions for processing the request or other means
(for example, via previous administrative consent).
Am working on an OpenID Provider implementation for Django.
https://github.com/juanifioren/django-openid-provider
Thanks for your time. Greetings.
Consent is a tricky business. There are different rules in different countries and even different interpretations within the same country. But that aside a common way of handling consent in SSO systems is to ask the user for consent the first time she appears from a specific client and then also ask if the choice should be remembered or if it should only be valid this once. Of course if the user says her consent should be remember she still should have the possibility to later redraw the consent but then outside the normal authorization flow.
You should ask for approval for a specific client only the first time that a user logs in to that client and then store it for later usage. In some use cases user consent is not required because it may be implicit, e.g. in an enterprise setting where users use internal clients.
ClientSiteA.com, ClientSiteB.com, ....
(client domains are unknown to us)
OurServer.com
(contains all the user credentials)
We need users to be able to login on OurServer.com (using JavaScript) on any client site. The login form must reside on client sites. So I am envisioning an ajax call sent to OurServer.com containing username (from any client site). If the username is logged in, let them do stuff, if not show them a login form. This login form will send their username/password to the server and log them in.
Is this possible? I've been reading about SAML, but I'm seeing having the login form on the client sites could be a problem. I've also been reading about oAuth. I'm pretty lost. Can anyone give me some guidance.
I don't think it is easier to have the same UI repeated over multiple sites, this makes maintenance much more difficult.
On the other hand, if there is an explicit link for users to login or they are automatically redirected when accessing restricted sites then there is NO need for this awkward requirement. Awkward - because it makes it tricky to use existing sso protocols.
Answering your question - OAuth2 lets you exchange username/passwords for access tokens. It is called the Resource Owner Password Credential flow.
Trying to convince you that this is not a good idea - not all OAuth2 providers support this flow, from what I remember Google doesn't. Instead, they support flows which redirect client to their login page where they can perform just anything your client application is not aware of like:
multifactor authentication
additional confirmation pages for explicit resource access approval
These additional steps of authentication are just not possible in the simple username/password flow.
What exactly is OAuth (Open Authorization)?
I have gleaned some information from
OAuth
Twitter Tutorial: What is OAuth And What It Means To You
What is OAuth
But I want to learn and know more. I'm looking for info on the lifecycle. Why do most of the social networks rely on this open protocol?
Will it become a de facto in near future with the various technologies (e.g. ASP.NET)?
What exactly is OAuth (Open Authorization)?
OAuth allows notifying a resource provider (e.g. Facebook) that the resource owner (e.g. you) grants permission to a third-party (e.g. a Facebook Application) access to their information (e.g. the list of your friends).
If you read it stated plainly, I would understand your confusion. So let's go with a concrete example: joining yet another social network!
Say you have an existing Gmail account. You decide to join LinkedIn. Adding all of your many, many friends manually is tiresome and error-prone. You might get fed up halfway or insert typos in their e-mail address for the invitation. So you might be tempted not to create an account after all.
Facing this situation, LinkedIn™ has the good idea to write a program that adds your list of friends automatically because computers are far more efficient and effective at tiresome and error-prone tasks. Since joining the network is now so easy, there is no way you would refuse such an offer, now would you?
Without an API for exchanging this list of contacts, you would have to give LinkedIn the username and password to your Gmail account, thereby giving them too much power.
This is where OAuth comes in. If your GMail supports the OAuth protocol, then LinkedIn can ask you to authorize them to access your Gmail list of contacts.
OAuth allows for:
Different access levels: read-only VS read-write. This allows you to grant access to your user list or bi-directional access to automatically synchronize your new LinkedIn friends to your Gmail contacts.
Access granularity: you can decide to grant access to only your contact information (username, e-mail, date of birth, etc.) or to your entire list of friends, calendar and whatnot.
It allows you to manage access from the resource provider's application. If the third-party application does not provide a mechanism for canceling access, you would be stuck with them having access to your information. With OAuth, there is a provision for revoking access at any time.
Will it become a de facto (standard?) in near future?
Well, although OAuth is a significant step forward, it doesn't solve problems if people don't use it correctly. For instance, if a resource provider gives only a single read-write access level to all your resources at once and doesn't provide a mechanism for managing access, then there is no point to it. In other words, OAuth is a framework to provide authorization functionality and not just authentication.
In practice, it fits the social network model very well. It is especially popular for those social networks that want to allow third-party "plugins". This is an area where access to the resources is inherently necessary and is also inherently unreliable (i.e. you have little or no quality control over those applications).
I haven't seen so many other uses out in the wild. I mean, I don't know of an online financial advisory firm that will access your bank records automatically, although it could technically be used that way.
What is OAuth?
OAuth is simply a secure authorization protocol that deals with the authorization of third-party applications to access the user data without exposing their password. (e.g. login with Facebook, gPlus, Twitter in many websites) all work under this protocol.
Parties involved
The Protocol becomes easier when you know the involved parties. Basically, there are three parties involved: OAuth Provider, OAuth Client, and Owner.
OAuth Client (Application Which wants to access your credential)
OAuth Provider (eg. Facebook, Twitter, etc.)
Owner (the person with Facebook, Twitter, etc. account )
How It Works
I have supposed a scenario where a website (Stack Overflow) needs to add a login with the Facebook feature. Thus Facebook is OAuth Provider and the Stack Overflow is OAuth Client.
This step is done by the app's developer. At the very beginning, Facebook (OAuth Provider) has no idea about the Stack Overflow (OAuth Client) because there is no link between them. So the very first step is to register Stack Overflow with Facebook developers site. This is done manually where developers need to give the app's information to Facebook like the app's name, website, logo, redirectUrl (important one). Then Stack Overflow is successfully registered, has got client Id, client secret, etc from Facebook, and is up and running with OAuth.
Now when Stack Overflow's user clicks login with Facebook button. Stack Overflow requests Facebook with ClientId (Facebook uses it to recognize the client) and redirectUrl (Facebook will return back to this URL after success). Thus the user gets redirected to the Facebook login page. This is the best part user(owner) is not giving their Facebook credential to Stack Overflow.
After Owner allows Stack Overflow to access the information. Then Facebook redirects back to Stack Overflow, along with authcode using the redirectUrl provided at step 2.
Then Stack Overflow contacts Facebook along with the obtained authcode to make sure everything is okay.
Only then Facebook will give access token to Stack Overflow. Then access token is used by Stack Overflow to retrieve the owner's information without using a password. This is the whole motive of OAuth, where actual credentials are never exposed to third-party applications.
For More:
Quick video
Web Link
Simply put OAuth is a way for applications to gain credentials to your information without directly getting your user login information to some website. For example if you write an application on your own website and want it to use data from a user's facebook account, you can use OAuth to get a token via a callback url and then use that token to make calls to the facebook API to get their use data until the token expires. Websites rely on it because it allows programmers to access their data without the user having to directly disclose their information and spread their credentials around online but still provide a level of protection to the data. Will it become the de facto method of authorization? Perhaps, it's been gaining a lot of support recently from Twitter, Facebook, and the likes where other programmers want to build applications around user data.
OAuth(Open Authorization) is an open standard for access granting/deligation protocol. It used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords. It does not deal with authentication.
Or
OAuth 2.0 is a protocol that allows a user to grant limited access to their resources on one site, to another site, without having to expose their credentials.
Analogy 1: Many luxury cars today come with a valet key. It is a special key you give the parking attendant and unlike your regular key, will not allow the car to drive more than a mile or two. Some valet keys will not open the trunk, while others will block access to your onboard cell phone address book. Regardless of what restrictions the valet key imposes, the idea is very clever. You give someone limited access to your car with a special key, while using your regular key to unlock everything. src from auth0
Analogy 2: Assume, we want to fill an application form for a bank account. Here Oauth works as, instead of filling the form by applicant, bank can fill the form using Adhaar or passport.
Here the following three entities are involved:
Applicant i.e. Owner
Bank Account is OAuth Client, they need information
Adhaar/Passport ID is OAuth Provider
Oauth is definitely gaining momentum and becoming popular among enterprise APIs as well.
In the app and data driven world, Enterprises are exposing APIs more and more to the outer world in line with Google, Facebook, twitter.
With this development a 3 way triangle of authentication gets formed
1) API provider- Any enterprise which exposes their assets by API, say Amazon,Target etc
2) Developer - The one who build mobile/other apps over this APIs
3) The end user- The end user of the service provided by the - say registered/guest users of Amazon
Now this develops a situation related to security - (I am listing few of these complexities)
1) You as an end user wants to allow the developer to access APIs on behalf of you.
2) The API provider has to authenticate the developer and the end user
3) The end user should be able to grant and revoke the permissions for the consent they have given
4) The developer can have varying level of trust with the API provider, in which the level of permissions given to her is different
The Oauth is an authorization framework which tries to solve the above mentioned problem in a standard way. With the prominence of APIs and Apps this problem will become more and more relevant and any standard which tries to solve it - be it ouath or any other - will be something to care about as an API provider/developer and even end user!
OAuth is all about delegating Authorization (choosing someone who can do Authorization for you). Note that Authentication and Authorization are different things. OAuth is Authorization (Access control), and if you want to implement Authentication (ID verification) also, OpenID protocol can be used on top of OAuth.
All big companies like Facebook, Google, Github,... use this kind of authentication/authorization nowadays. For example, I just signed in on this website using my Google account, this means Stackoverflow doesn't know my password, it receives the allowance from Google where my password (hashed obviously) is saved. This gives a lot of benefits, one of them is; In the near future you won't have to make several accounts on every website. One website (which you trust most) can be used to login to all other websites. So you'll only have to remember one password.
OAuth happened when we sign up SO account with Facebook/ Google
button.
Application (SO) redirecting user to the provider's authorization URL. ( Displaying a web page asking the user if he or she wishes to grant the application access to read and update their data).
User agree to grant the application process.
Service provider redirects user back to application (SO), passing authorization code as parameter.
SO exchanges the code for an access grant.
Source : OAuth1 service providers
OAuth is an open standard for authorization, commonly used as a way for Internet users to log into third party websites using their Microsoft, Google, Facebook or Twitter accounts without exposing their password.
Authorization: OAuth as it name suggests is simply a standard for Authorization.
Used for log into third party websites: With OAuth, you can log into third party websites with your Google, Facebook, Twitter or Microsoft accounts without having the necessity to provide your passwords.
Remembering passwords: Using OAuth you can avoid creating accounts and remembering passwords on each and every web application that you use on the Internet.
Access token: OAuth is based on an access token concept. When a person authenticate hinself using his Google account, to a third party web application. Google authorization server issues an access token for that web application the person is using. Thus, the web application can use that access token to access his data hosted in the resource server. In the case of Google, your Gmail inbox, contacts, photos etc. are the resources. So, any third party application can access those resources, for an example view his Gmail inbox using OAuth. Hence, OAuth is a simple way to publish and interact with protected resource data. It’s also a safer and more secure way for people to give you access to their resource data.
OAuth2 and HTTPS: OAuth2 uses HTTPS for communication between the client and the authorization server because of confidential data for example client credentials. passing between the two applications.
OAuth is a protocol that is used from Resource Owner(facebook, google, tweeter, microsoft live and so on) to provide a needed information, or to provide a permission for write success to third party system(your site for example). Most likely without OAuth protocol the credentials should be available for the third part systems which will be inappropriate way of communication between those systems.