Using the OWIN and Thinkecture components are very powerful. I have an MVC app that is fully secured using an Identity Server we built on Thinkecture. It can call our web api secured as a resource through our IDS.
We now have a new feature that we need to call out to a 3rd party and access their API to grab some data. They also protect their api through oauth2 using their identity services. I thoght doing this would be straight forward, but I am struggling figuring out the actual code to do this. Basically they request a page in our MVC app. It requires authorization, but that is authorization from our IDS. We lookup the access and refresh token to use for our user to call the 3rd party. If not found or if it is expired, we need to authorize with the 3rd party by having the user login to their IDS, give consent, etc.
I could not find any client examples to handle this. Can someone point me to an example or point me in the right direction?
I looked closer at the IdentityServer3 samples and found the MVC manual Code Flow client and dug into it a little bit. I was able to take the code from there and alter it a little bit to save off nonce and state a different way and then was able to accomplish what I wanted.
Related
I have a DashboardApi and an EnterpriseApi on my system. May be one more later.
I am new at IdentityServer3 and I wonder solve my problem.
IdentityServer saves client applications that will use an api. So I have 2 or 3 api. Will I create IdentityServer for all api? Because DashboardApi will consume EnterpriseApi. EnterpriseApi will consume another api.
And users will login to Dashboard application. I could not imagine the organisation.
To answer the question: you may have one instance of IdentityServer being your identity provider/authority across different "resource" APIs as long as they all point back to that same authority when it comes to token validation.
Then an access token used for "DashboardApi" can be used by "EnterpriseApi". It is important to proxy the token properly and in my experience it would be advantageous to create different scopes for each API to have better access as to which calls may be used to proxy into the second API through the first (especially if user consent is a concern).
I am developing a WebAPI over my already existant MVC application, using the OAuth2 authorization system.
This API will allow my clients to request my users information. Currently, my users are stored in the Identity tables (ASPNetUsers). In my application, they are registering, logging in, etc... with the help of the Identity classes and methods.
The problem is here : I want to manage my API clients accounts, in an "Identity way", so I can authenticate them when they ask for Access Tokens. But I can't use the current users tables, as there is no common points between my clients and my users.
The perfect solution would be to have two Identity tables : one for my users, and one for my clients, but after my long-time searches, I figured it was not possible, or it would be a mess, at best.
I would not use ASP.NET Identity as a way to manage OAuth2 registered client applications. Even though some client applications (confidential) are indeed issued client credentials that's probably the only thing they share with a username/password user identity. It's a completely different thing and as such it should be managed and stored independently.
If you're thinking that this sounds like a lot of work, you're absolutely right. It isn't trivial to implement a custom username/password authentication that proves secure and implementing an OAuth2 authorization server is many times as complex.
If you really want/need to go that route then some mandatory reading:
The OAuth 2.0 Authorization Framework
OAuth 2.0 Threat Model and Security Considerations
JSON Web Token (JWT) (assuming you choose JWT as token format)
If you're still evaluating all your options I would also consider the possibility of delegating all the authentication/authorization work onto a third-party, Auth0 comes to mind, but I'm biased because I work there.
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 starting a new system creating using .NET MVC - which is a relatively large scale business management platform. There's some indication that we'll open the platform to public once it is released and pass the market test.
We will be using ExtJs for the front-end which leads us to implement most data mining work return in JSON format - this makes me think whether I should learn the OAuth right now and try to embed the OAuth concept right from the beginning?
Basically the platform we want to create will initially fully implemented internally with a widget system; our boss is thinking to learn from Twitter to build just a core database and spread out all different features into other modules that can be integrated into the platform. To secure that in the beginning I proposed intranet implementation which is safer without much authentication required; however they think it will be once-for-all efforts if we can get a good implementation like OAuth into the platform as we start? (We are team of 6 and none of us know much about OAuth in fact!)
I don't know much about OAuth, so if it's worth to implement at the beginning of our system, I'll have to take a look and have my vote next week for OAuth in our meeting. This may effect how we gonna implement the whole web service thing, so may I ask anyone who's done large-scale web service /application before give some thoughts and advice for me?
Thanks.
OAuth 1 is nice if you want to use HTTP connections. If you can simply enforce HTTPS connections for all users, you might want to use OAuth 2, which is hardly more than a shared token between the client and server that's sent for each single request, plus a pre-defined way to get permission from the user via a web interface.
If you have to accept plain HTTP as well, OAuth 1 is really nice. It protects against replay attacks, packet injection or modification, uses a shared secret instead of shared token, etc. It is, however, a bit harder to implement than OAuth 2.
OAuth 2 is mostly about how to exchange username/password combinations for an access token, while OAuth 1 is mostly about how make semi-secure requests to a server over an unencrypted connection. If you don't need any of that, don't use OAuth. In many cases, Basic HTTP Authentication via HTTPS will do just fine.
OAuth is a standard for authentication and authorization. You can read about it in many places and learn; Generally the standard lets a client register in the authentication server, and then whenever this client attempts to access a protected resource, he is directed to the auth-server to get a token (first he gets a code, then he exchanges it with a token). But this is only generally, there are tons of details and options here...
Basically, one needs a good reason to use oAuth. If a simpler authentication mechanism is good for you - go for it.
I have been implementing a skeleton Claims Based architecture for our services and websites. I'm using WIF, .NET 4.5, MVC / Web Api.
I have the STS (WS-Federation / WS-Trust) and several Relying Parties implemented, and all is working fine.
Now, I want to be able to authenticate in one Relying Party and use that same token (the bootstrap token, I assume) to make Ajax calls to another Relying Party. I can get the Bootstrap Token down in the HTML (is this even a good idea?), and add it to the Ajax call headers as some form of Authentication (Basic, etc).
What I don't know is how to intercept the request in the final Relying party, and "tell" WIF to use that bootstrap token and do it's magic with it (Load, Validate, Authenticate, Authorize, Create Principal, Create Session Token, Write it down in a cooke).
I guess I could do all this by hand using the available classes, but there must be a point where I can just hook up for this. Probably around the SAM / FAM modules, but I can't understand exactly how.
Any ideas?
Thanks
SAML is not a good fit for being consumed in html. The format is complex and relies too much on WS-Security for cryptography. I see more adoption these days of OAuth2 (It was OAuth-Wrap in the past), although is complex as well. If you want to explore that path, I recommend the ThinkTecture Identity Server as a quick solution.
http://weblogs.thinktecture.com/cweyer/2012/11/oauth2-in-thinktecture-identityserver-v2-implicit-grant-flow-with-javascript.html
Thanks
Pablo.