As far as I can tell, OAuth 2.0 expects user information requests to be retrieved from a single endpoint, but the LinkedIn v2 API separates email into a separate endpoint from other basic user information (id, name and profile image).
Our product's generic OAuth 2 implementation only handles a single user info endpoint, so I'm trying to determine whether our implementation is incomplete, or if it's a problem with the implementation on the LinkedIn side (or the third option, there is a way to do it that I have not found).
Breaking the problem into 2 logical questions:
1) Does separating that information into 2 endpoints comply with OAuth 2.0?
2) Have I missed something, and is there a way to fetch email along with other basic user information (which was previously combined in the v1 basic user info endpoint)?
I have looked through all of the v2 API documentation, in particular the migration docs (https://learn.microsoft.com/en-us/linkedin/consumer/integrations/self-serve/migration-faq?context=linkedin/consumer/context) and related information about the endpoint changes, as well as various OAuth 2 documentation / open ID specifications.
Related
OAuth 2.0 protocol provides permissions delegation of a user so that third-party apps can operate on its behalf. A typical way this is done on the OAuth flow is requesting a user consent to either approve or deny access for the app (Okta example). Here is an official spec describing how it works in general concepts.
I'm looking for the standardized approach to perform the same flow but for the user groups (e.g. organizations). GitHub does that in some way for organizations, so it looks like organizations represent just a group of user accounts. Are there any standardized approaches to this problem?
If not maybe there are any recommended ways how its typically done architecturally or can fit into OAuth 2.0/OpenID Connect protocols.
The OAuth 2.0/OpenID Connect protocols do not cover how access control is performed.
You can, within the OAuth 2.0/OpenID Connect protocols, pass OAuth Scopes or use the OIDC user info endpoint data to allow the resource server to make determination for Access Control.
Many of the commercial products within this area allow the use of LDAP as a back-end for authentication and will even convert LDAP Groups to Scopes.
I would assume, but I do not know, that GtHub stores data with a link (like a group) for the on Organization and/or the user. I know GitHub exposes this using OAuth Scopes.
Oh, and the OAuth Spec is at: https://oauth.net/2/
But if you require Authentication of users then you need to be using OpenID Connect which is built on-top of OAuth 2.0.
Remember that "OAuth 2.0 is NOT an Authentication protocol"
-jim
There are limits to what you can show on the consent screen and dynamically calculated data is not usually supported.
You ought to be able to express a high level scope that you can present to the user though.
In terms of authorizing based on a user's organisations the claims caching technique here can be useful:
https://authguidance.com/2017/10/03/api-tokens-claims/
That is:
* Use OAuth for user identification and high level checks
" Then do the real Authorization based on your back end data
I'm making some assumptions here, but I believe the issue arises from trying to authenticate two things at once.
If the organization is what you need, then go ahead and create a flow to authenticate the organization as the principal subject (via a user who has access to it), instead of actually authenticating the user itself.
Once the access token is generated, you do not necessarily need to know which user generated it anymore (or at least, the token itself does not need to know). If your user needs to be able to view and/or revoke access tokens, they should still be able to do that, since they have access to the organization in your app.
After reading the article How To Control User Identity Within Microservices I've been trying to implement such access control scheme (Value and Reference Tokens), but after going through multiple other topics and examples in GitHub related to Spring Security + OAuth + Zuul, I couldn't find concrete examples on how this can be achieved. All the examples that involve JWT return User Details when the token is returned, and that is what I would like to avoid. The User Details should never reach the Client directly but should be passed to the backend services instead. The tutorial Spring Security + AngularJs has a lot of information on how to evolve an application towards a secure one, but uses an Access Token or mentions the possibility of getting the User Details directly via JWT.
This SO question, Using Zuul as an authentication gateway by #phoenix7360, is exactly the approach I've been trying to implement but it only supplies a brief overview of the configuration required to carry out this kind of security approach for microservices. Please refer to the image in this question for a clear picture of how it would go.
I can't fully get my head around how the Zuul Pre-Filter should be configured and what the Authorization Server's configuration should look like. As stated in both the article and the SO question, the flow would go something like this:
External (HTTPS)
The client authenticates against OAuth2 Server
OAuth Server returns an opaque Access Token (a UUID with no other information)
The client sends the request to the API Gateway with the Access Token in the Authorization header
API Gateway requests User Details to the OAuth Server with the Access Token in the Authorization header
OAuth Server checks the Access Token is valid and returns User Information in JSON format
Internal (HTTP/S)
API Gateway creates a JWT with User Details and signs it with a private key
API Gateway adds the JWT to request and forwards it to Resource Server
Resource Server verifies the JWT using API Gateway's public key
Note: API Gateway should return an error if OAuth Server indicates Access Token is no longer valid.
How would the ZuulFilter work? Does a new request need to be issued against the OAuth Server (for instance, via RestTemplate), or are these schemes supported with the current implementation? Is there any particular configuration required for the JavaConfig classes for both OAuth and Zuul? If someone knows of a working example that would be really helpful and would be great for future reference regarding this topic.
I'm using Spring Boot (1.4.0-M3) + Spring OAuth + Spring Cloud (Eureka, Ribbon, Zuul)
I know this question is very similar to the one linked previously, and if this is not the right way of doing it I apologize, but I thought a new thread would be better than asking for help on a SO thread that aimed at solving another problem.
Thanks in advance!
JHipster does a pretty good job in handling this issue. If I want to tell the login process briefly, first you do login, in time you fetch every information you need to pass to your below services (such as username,email,etc) then you pass them to your microservices.
you can see the link below from okta for more information
https://developer.okta.com/blog/2018/03/01/develop-microservices-jhipster-oauth
I would like to know if One Drive supports those four ways of Authorization. Please refer to this link. https://www.rfc-editor.org/rfc/rfc6749#page-23
We are integrating our DVR and NVR with One Drive now and we need to understand which authorization method One Drive supports. We are trying to use OneDrive with embedded ARM processors, so the user does not have access to a browser as they would for a web-app.
Please kindly advise how we should proceed from here. Thanks for your time and I look forward to hearing from you.
Best Wishes,
Ted Yang
I am going to say yes, OneDrive probably supports those ways of authorization, because on their authentication documentations page they say the following:
The OneDrive API uses the standard OAuth 2.0 authentication scheme to authenticate users and generate access tokens.
That link takes us to the oauth.net site page for OAuth 2.0. On that page, we find the following:
The final version of the spec can be found at https://www.rfc-editor.org/rfc/rfc6749
which is the document you linked. The OneDrive API documentation says it supports OAuth 2.0, and your linking the definition of OAuth 2.0, so I think it's safe to say it's supported. How to use it is another question entirely, and one I am unable to answer.
I will note, however, that on the OAuth page, they have this to say about it's uses (emphasis mine):
OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices.
I would presume that living room devices could include DVRs, and although your DVRs are for security purposes, the development of cloud storage APIs for either would undoubtedly be similar. So I would say this is probably quite possible.
How to do it:
First things first, you'll need to register your app. This gets you a client id and a client secret which you'll need. Registration directions
There are two methods: token flow and code flow. Token flow is two steps, and code flow is three steps. However token flow uses tokens that expire, so it would require the user to reenter thigns periodically. You therefor want to use code flow. Here's some directions for that.
Basically the steps of the code flow are:
Get an authorization code
User authorization code to get an access token
User access token to make API calls
You WILL need to make HTTP requests. I'm sure you should be able to do this with ARM embedded C. However, step 1 is what gives you to the Microsoft account login page. I am note sure how to circumvent this, exactly. I'm not sure you're supposed to be ABLE to circumvent this, since Microsoft doesn't want you handling their customers' passwords.
They have an example in Javascript that might give useful details on oauth in the oauth.js file. Javascript sample project
I'm trying to obtain an Google OAuth 2.0 access token for a service account but receive an invalid_grant error instead. I've checked my various artifacts (private key, etc.) and clock timings but have not been able to resolve this so far.
There is one possibly related item that seems odd: Google's documentation says
Three parameters are required in the HTTPs POST, and these are shown
below
This is followed by a table with two rows that specifies two parameters (grant_type and assertion). Could it be that a third is also needed (I've seen examples that also use assertion_type in some fashion)? Could it be that (some) Google engineers (or perhaps yours truly) cannot count up to three? :)
In summary: What are the appropriate parameters? It seems unclear from Google's current documentation.
UPDATE: Here is some further information: I can't use the Google API Client Library, because my application requires a language other than those currently not supported by Google. Therefore I have to implement the logic for creating and signing JWTs, etc., as is normally discouraged. I have confirmed that my service account artifacts are in order: I can use them with the Google APIs Client Library for Java to access the same calendar (from another than my target platform, i.e.). In particular, my "client_id" is of the form "...#developer.gserviceaccount.com" and my key is a 128-bit RSA private key, both as obtained from the Google APIs Dashboard.
I've now been able to confirm that it's two parameters, not three. Google's documentation seems to be correct insofar as it names those two parameters (grant_type and assertion) but wrong insofar as it refers to them as three parameters.
Evidence for two parameters comes from a current Internet-Draft (JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0), which defines an extension grant type under RFC 6749 (The OAuth 2.0 Authorization Framework).
Evidence also consists of having tried a verbatim access token obtained by the Google APIs client library (and revealed by logging) inside my (non-Java) implementation: use of this access token has made the invalid_grant error go away.
(There now evidently a problem about forming a SHA256withRSA signature left in my code, but that's another issue ...)
<context> I got frustrated yesterday and posted a flame question which was quickly (and appropriately) closed and deleted by my fellow SO cohorts. Yahoo! turned off its standard PlaceFinder API endpoint and replaced it with a paid service. That's not the part that frustrated me though, it was mostly the fact that they changed their access model to require OAuth. One of the closers of my question commented something to the effect of:
you didn't keep an eye on deprecations of API's you depend on, OAuth
is better for users, suck it up.
While I could argue the facts of my API-watching by again blaming Yahoo for having broken links when they first announced the API deprecation back in October / November of last year, I think it would be more productive to try and turn this into an intelligent question. </context>
I have used OAuth. I like OAuth. Not only does it let you authenticate users and simplify sign ons to your application, it lets you ask for authorization to access that user's data from other apps. But PlaceFinder data is not private user data. It is for known place names and global identifiers (WOE ID's) that can be shared by everyone.
This morning I gave Yahoo! BOSS GEO my credit card information and started spiking up an OAuth API consumer to test it out. I started with DotNetOpenAuth, which I have used in the past. I read through Yahoo!'s OAuth guide and created a DotNetOpenAuth.OAuth.ServiceProviderDescription instance with all of Yahoo!'s OAuth 6.1, 6.2, and 6.3 endpoint URL's. I then went about trying to figure out how to use DotNetOpenAuth.OAuth.WebConsumer to hit the PlaceFinder API and start giving money to Yahoo!.
But it didn't work. I had to overcome a lot of cognitive dissonance, and in the end, either a limitation of the popular and widely-used DotNetOpenAuth library itself or a possible misuse of OAuth. When I finally realized that the BOSS documentation was separate from the BOSS GEO documentation, and found a C# code sample that worked to consume Yahoo!'s PlaceFinder API, I discovered where all of that dissonance was coming from.
Yahoo!'s PlaceFinder API, while it uses OAuth, does not require an Access Token to get at the API's endpoints or data. When you send a PlaceFinder request, you send all of your app's information (consumer key and secret), along with the timestamp, nonce, and signature to the PlaceFinder endpoint itself. When I used OAuth in the past, these elements were sent to the 6.1 endpoint to obtain a request token. You could then use that to authenticate / authorize the user (6.2) and obtain an Access Token (6.3) to make further requests.
Here's the limitation in DotNetOpenAuth that I can't overcome so far, so if I'm being ignorant and doing it wrong here please tell me. In the sample C# code on Yahoo!'s site, they are not using DotNetOpenAuth. Instead they have an OAuthBase class that you can use to generate a nonce, timestamp, and signature. But they send empty strings for the access token and secret. I tried doing this with DotNetOpenAuth, but it won't let you construct any requests with a null or empty access token.
So the question: Is this an inappropriate use of the OAuth standard? If not, is there a limitation in the DotNetOpenAuth library that makes it impossible to send unauthorized requests to endpoints other than for a RequestToken (6.1)? If the answer to both of these is no, how could you use DotNetOpenAuth to request PlaceFinder data without having to send an access token or secret?
This is a great question. I think oAuth provides BOSS developers with two benefits
Since you sign up for BOSS once and can then use that key for multiple services, the BOSS team wanted to have the flexibility to offer more services that needed tokens in the future. Starting with oAuth right from the get go allowed that flexibility.
The team wanted to ensure that keys are not sniffed out during network communication. Since requests are signed and actual keys are not passed, we can ensure that no sniffing happens.
Regarding your question on DotNetOpenAuth, I recommend asking on the BOSS Y! group (http://tech.groups.yahoo.com/group/ysearchboss/) since we have a number of folks who have written in C#, VB.Net who can advise you. In fact it is well known that the VB.Net oAuth library (http://oauth.googlecode.com/svn/code/vbnet/oAuth.vb) has some issues with it.
There's two types of oAth that yahoo uses. One requires a key, one doesn't. You probably want the one that doesn't for general API use. Just add the secure protocol http:// -> https:// and then place /public/ in an appropriate spot of the old url like
https://somePartOfURL/public/otherPartOfURL