Ok - I'm a DotNetOpenAuth newb, just to get that out of the way.
Here's a little overview first
I'm building an app that will be an OAuth consumer of another app. This other app has what they call an "App Marketplace" where users who are logged into their site can launch consumer sites directly. This marketplace will contain a link to our app - and when clicked on will already contain the request token and request token secret. With that said, we obviously don't have to make the OAuth request to get the request token, etc, because we already have it.
Now - here's my problem
From what I can tell - DotNetOpenAuth doesn't seem to contain a way to skip the first couple of requests in the authorization process and go straight to the request to get the access token. Now, obviously, I can build my own HttpWebRequest to get it, but I was hoping to not have to do that since DotNetOpenAuth hides all that messy Authorization header stuff out of plain sight. So, anyone know of any way to skip to the access token step going through DotNetOpenAuth?
I tried calling WebConsumer.Send(PrepareRequestUserAuthorization()) but that seems to start the OAuth authorization from the beginning. I also tried calling WebConsumer.ProcessUserAuthorization() but that just returns null. And, to be quite frank, the documentation around DotNetOpenAuth isn't specific enough for this newb to determine what exactly these methods are supposed to do anyway. So, any help would be much appreciated.
What this app marketplace is proposing is not standard OAuth 1.0(a), and therefore not something that DotNetOpenAuth supports. That said, you could play a few tricks to make it work. Calling WebConsumer.ProcessUserAuthorization(HttpRequestInfo) with a carefully crafted argument would "fool" DotNetOpenAuth into proceeding from the point this app marketplace leaves you. You would need to craft the HttpRequestInfo object such that it contains all the message parts that would be included in a normal OAuth flow when the request token has been authorized:
oauth_token
oauth_verifier (if this is an OAuth 1.0a flow)
In addition, you'd need to artificially inject the request token and its secret into your instance of the token manager in WebConsumer.TokenManager. This also may not be trivial, depending on how you're implementing it.
I would caution you though, that whenever you depart from the standard OAuth flow, thorough security reviews are critical, because you may be defeating security mechanisms built into the protocol.
Related
I'm building an application in WPF that is client side and will only depend on external API.
To this point I could use open API which I build in RestSharp and everything worked well. But from last week this API uses CAS authentication, so to use them I need to be authenticated. API I want to call is in external server. They have two API's and my assumption is that if I will log in on their site using CAS then I will be able to use this auth for my API calls for second API.
I'm new to SSO, CAS and security overall, so this was my first thought: I will build WebBrowser control, get returned TGC cookie and use ticket from it to use in requests I will be making. But this failed, setting cookie still got me and 401 error and from what I understand from CAS auth for now, TGC is a go to for checking if I'm an authenticated user in current session?
My next thought was to use some CAS c# library. Unfortunately all of advices / libraries focus on creating CAS in .NET projects. Is there some library which will provide a way to log in to CAS auth and then allow me to make API calls?
I hope this makes sense and I didn't messed up things completely. I'm new to secutity and I will be grateful for any help or guidance how to approach this problem. Things I have: API specification (endpoints paths) and username and password to log in to the system.
Is there a way for a native/WPF application to get Identity Server 4 to issue a token without the need for a user interface in the way that Microsoft's MSAL library allows you to - https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/wiki/Integrated-Windows-Authentication.
The MSAL library only works where you have a Windows user that is backed up in the Azure AD tenant specified by the authority property.
Using the .NET HttpClient class, I was hoping that if I set the UseDefaultCredentials in the HttpClientHandler and setup Identity Server so it uses Windows Authentication as its "provider" that this would be possible.
However when trying it I get a 401 Unauthorized when it tries to authenticate the user at this point in the Quick Start example. I suspect I'm getting Windows Auth problems with the HttpClient class even before we get into Identity Server specifics.
If I got past this stage I would also need to be able to handle the callback to deal with the code/access token. Is there another way to do this?
I realise that a browser window can be shown in WPF to handle everything but for complicated and political reasons within the company we would like to avoid this if possible.
So the proper way to do this is use Auth Code with PKCE, you can configure this to give you a refresh token, so you can argue that you only see the browser once when initially logging in. (I advise this)
If you can't get a refresh token, you can do silent refreshes with headless browser.
If you don't want the browser window you can again have a headless browser and just interact with it via the UI, and simulate the flow without anyone seeing it. (I do not advise this)
If you don't want the browser at all, you can use Resource Owner Password Credentials flow. Please refer to Scott Brady's blog post about weather you should or shouldn't use it.
Many members of the OAuth Working Group now consider the ROPC grant type as deprecated.
And as for
I realise that a browser window can be shown in WPF to handle everything but for complicated and political reasons within the company we would like to avoid this if possible.
Tell them it's impossible to avoid this.
I have been asked to implement integration with a SAML 2.0 IdP for user Authentication purposes. I have never worked with any federated authorization processes so this is all new to me so please forgive if I am asking a stupid question but here it goes.
For My needs all I want is to send a SAMLP Authentication request. If I get a response that says the user is valid I will give them access to my system which will have a user id that matches what is returned. From that point on all authorization is to be performed by my system and I do not need to send a token with each request to the SAML IdP. After they log in I am done with the IdP.
Many of the questions and examples I see on here and other sites include adding extensive libraries to my project. When I look at them and the documentation around them they all seem to want to either perform the authentication with every request through an IIS Module or through integration with the MVC routing mechanism.
So now to my question. Can't I just create the XML myself and stick it on the the querystring as the SAMLRequest value? Then parse the response XML that comes back for the values I need? If this is a valid way of doing it does anyone have some example code that does this?
Any help would be greatly appreciated
The flow that you describe is how things are normally done: One SAML2 request to the Idp to authenticate the user, and then setting a session cookie for all subsequent requests.
Don't create this yourself unless you want to investigate substantial time to understand SAML2 and XML signature validation rules. They are complex and most custom implementations get it wrong, resulting in compromised security.
My own library, Kentor.AuthServices works the way you want. Even though it comes either as an httpmodule, an mvc controller or an owin middleware, it only interfers with the first requests that make up the actual sign in. All subsequent requests are just passed through and the session cookie mechanism handles the session authentication.
I'm creating a WebAPI based SaaS application. This WebAPI can be used alone without the need for a user interface, requires a basic authentication sent with every request made to the WebAPI and returns some objects when the methods are called and authenticated.
Now I'm facing a big problem: I'm creating a WebApp in MVC (but it could be any language) and I can't figure out how to call my WebAPI endpoint without the need to keep username and password in order to authenticate the WebAPI request every time I call a method.
What are the best practices in this particular case?
I can't seem to find any suitable solutions...
So far I have tried to create a custom cookie with the help of a custom implementation of the HttpContext.Response.Cookies.Add method, where I store in the userData of the Cookie the pair of username and password encrypted. In this way I can call the WebAPI methods specifying each time the BasicAuthenticationCredentials with the correct username and password, but this seems to me a very unmaintainable way to do the job in the long run.
I also wanted to try the OAuth2 way, but I can't find a well written guide on how to implement an authentication server based on a custom user table from SQL Server (and the first five pages of the Google result list didn't help me, they did actually make me even more confused about this topic, the whole OWIN and Katana thing...).
I can provide further information in case someone is willing to help me out.
Thanks in advance,
Stefano.
Here's a good tutorial about how to implement your own OAuth2 server:
http://bitoftech.net/2014/06/01/token-based-authentication-asp-net-web-api-2-owin-asp-net-identity/
The main idea behind using OAuth is that you'll only need a username and password for your first request, and after that, you'll get an access token that will be used to get access to the API. This access token will have a lifetime, and once it has expired, the user will need to request a new access token (either by sending the user credentials again, or by using a refresh token that will be used as a credentials substitute).
The nice part behind this approach is that since the access tokens have a lifetime, even if one of those tokens gets compromised, you can just revoke it (or wait until it expires, for example, you can create tokens that will be renewed every 5 minutes or even less. It's up to you), the client will automatically ask for a new one, and that will be the end of the story. On the other hand, if you were always receiving the user credentials and those credentials got compromised, the user will need to change them and the risk will be there until the user finally changes his credentials (and here's a manual process where the user needs to be aware about this problem, while the OAuth approach is just refreshing those tokens all the time).
Also, remember to keep all the communication over HTTPS, since the tokens are sensitive information, and you don't want an eavesdropper getting the access token or even worse, the refresh token by just intercepting the communication. If he's able to do something like this, then even tokens refreshing every minute will be a useless approach against someone getting every token that you send.
I need to implement authentication for some web services that we will be hosting. I want to use open standards, so I am interested in OAuth.
I will be using WebAPI for these services.
So here's where I'm running into trouble: Most (or maybe all) of the Api Key/OAuth scenerios that I have read involve (at some point or another) a user sitting in front of a screen.
I need to put together an API that a business partner will be calling. The calls will come from an automated process -- nowhere in the chain will there be a person who can be redirected to a web site with logon credentials.
However, I don't want just anyone coming around and calling my services.
So, I read about OAuth, and how it uses a shared secret to sign each request, and I think that's what I'm after. (I would either set up a session key, or could consider making one of the parameters a "ticks" value, and only accept requests within a short timeframe, etc)
I was kind of hoping that I could use DotNetOpenAuth to accomplish this (or something like it), but every example I come across begins with "the user gets redirected to a login page). I only need "2 leg" authentication.
Is there an example of using DotNetOpenAuth to do this?
Is there a better way to go?
If you are looking at OAuth 2 then the flow you are describing is the Client Credentials Grant
This kind of "two legged" / "service account" type flow is one that doesn't have a web page based flow.
DotNetOpenAuth supports the Client Credentials Grant. You can see an example of it in action here; however, be aware even though the author states it is the "Resource Owner Password Credentials" grant it is actually the Client Credentials Grant.
The blog post above was a little out of step with the latest DotNetOpenAuth code base but these are quickly identified and altered.
I believe that as it stands the DotNetOpenAuth only supports issuing a Bearer token using Http Basic authentication. There are other more exotic extensions OAuth 2 with a similar flow e.g. the JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants (but as stated this is not yet part of DotNetOpenAuth).