I have a webpage(Angular), which authenticates the user, after login in(oAuth2), the user has an option to interact with the bot (Bot Framework v4 C#) as of now I had the bot Independent, hence had used the OAuthCard in the bot to authenticate the user.
Now I want to have a Single Sign-on. I am not sure how the user token will be passed from the webpage to the bot, I have two scenarios now sure which is the correct one:
1. Send the user token with every message, requires validation on every message, too much computation.
2. Send the token with a TTL, and handle the expiry.
But for now, I am not sure how to send the token from the Webpage to the C# App.
I did go through this, and as it says
"A third option, called Single Sign-On (SSO), is in development and is where the client UI takes the client’s user token for the client app and exchanges it for a different token that can be used with the same identity provider, but a different app/scopes. For now, it is possible to create a similar user experience using WebChat by using technique #1 above."
And the document seems a bit too sparse to understand how exactly it was done with technique #1
I agree, that blog post is quite confusing and I still have no clue what they're intending to eventually do for what they describe as the "SSO scenario". The major difference they describe there from simply handing the bot the token from the SPA is that they will do some sort of token exchange for a different set of scopes that the bot needs vs the SPA. This would certainly be useful, but, as of right now, it's "all talk" and I'm not aware of anything they've built to enable it.
Let me just address your two points real quick first..
Send the user token with every message, requires validation on every message, too much computation.
First off, I would venture to say that the majority of the web is built on token exchange at this point. Tokens need to be continually passed around, signatures validated and then checked for expiry. This is just the nature of authentication; I don't think this is a bot specific problem.
Send the token with a TTL, and handle the expiry.
Are you using JWTs? They have TTL built into them via the standard exp claim, so you shouldn't need to worry about inventing your own TTL. Yes, you do need to check for expiry.
Ok, that said, if you're concerned with the overhead of constantly passing the token to the bot, you can choose to send it once via a custom, "backchannel" event over the DirectLine connection. Your bot can then take this token, validate it once and associate it with the conversation state so that the client need not send it on every request. Keep in mind however, you will still need to continually validate the token has not expired.
This backchannel event and the handling of it would be completely proprietary (e.g. there is nothing in the box to do this for you today). Just like you would have an event from the client to the bot to send the token in, you can also have an event that goes from the bot to the client to tell it it needs a token from the client (e.g. first request, or refreshed one because of expiry).
Related
I am creating a .NET class library which will allow local applications to access the accounts of users registered on my website, using an API. I would like the library to handle all authentication of users, so that any app I create an simply call the library, and be returned a token for the API. I'm not sure how to do this authentication.
There are a couple of ways I have considered doing this, however they are not ideal. The first would be to simply create a login form within the library which asks users to enter their login then calls the API. The second method would be to have a webpage where the user logs in and is then given the token which they enter into the app.
The ideal scenario for this situation is that the user does not see their token, and the actual login process is delegated to the website if possible. Both of the above ways lose out on one of those conditions.
The ideal way I would like to do this is inspired from an app I use where if the user is not logged in, they must press a 'Sign In' button, which opens a webpage where they log in. Once they have done so successfully the app automatically detects this and they are signed into the app. The downfall of this solution is that I have no idea how I might do that myself.
Essentially what I'm asking is, is the third solution viable, and how could I do it, or if not are there any better solutions I've overlooked.
FYI the website and API run ASP.NET MVC and WebAPI respectively and the library will use .NET framework.
Edit:
From the comment below it seems likely that you'll want to implement an authentication provider using something like OAuth. The .NET reference libraries can be found here and there's a similar answer already on StackOverflow that may also shed some light.
Welcome to Stack Overflow!
Personally, I would keep the Web API as the authority on authenticating a user and just consume this HTTP endpoint on all platforms (web, desktop, mobile etc) whenever you want to validate a user's credentials.
At a high level the process would be along the lines of:
Have your "clients" (desktop, mobile, web applications) submit HTTP requests to an API route (something like /authenticate) when the user first logs in.
Run your authentication logic
If successful return a token (and cache this this for use in subsequent requests)
Otherwise return a 401 response
Every client will now get a standardised response they can use for determining if they should redirect the user to some protected area, or show them an error message.
This also allows you to design login screens that are native to the platform they're running on (which is a smoother user experience). I wouldn't recommend having a library return a pre-built login page to the user - you'll find that becomes a real pain to maintain!
The third solution you proposed is also a valid way of doing things - but it does have the side effect of redirecting the user's focus away from the application they're using - which you may not want depending on your use case. It's also a bit trickier to implement than just calling the API directly, so unless you have a specific requirement to do it this way I'd not recommend it.
Hopefully this makes some sense. If you are unsure on how to implement cross application authentication then I'd recommend taking a look at some existing answers on Stack Overflow such as:
Basic token checking
OAuth
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).
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.
I have an application that I've developed in .NET 4.0/C#. It's designed to be used by customers that want to watch hardware sensors and alert them of specific values. One option for notification is by "tweeting" to a Twitter account of their choice. Before Twitter changed to OAuth, users entered their account name and password and this was enough to send Tweets on their behalf.
After reading up on the Twitter API and OAuth, I want to see if I understand correctly the best way to maintain this functionality.
I've registered my application with dev.twitter.com and obtained the necessary Consumer Key and Consumer Secret.
The application may potentially need to tweet to more than one Twitter account as it is used by multiple users per installation.
If I understand things correctly I will need to do the following:
Provide some sort of "Request Authorization" button on a per-user basis, which launches a Twitter authentication web site. There, the user logs in and is then provided with a PIN number.
Use the PIN number to obtain the user's AccessToken and AccessTokenSecret.
Store both of these tokens between sessions (launches) of the application.
My questions:
Should I encrypt either of these tokens when storing (in SQL)?
Is it ever necessary to re-authorize? The program is intended to be setup just once, then run unattended. Re-authorizing accounts will be a deal-breaker.
Though it shouldn't affect any answers or advice, I am using the TweetSharp library.
Your understanding seems pretty good to me.
It depends on how you store your consumer key and secret. If an attacker could gain those and the user's tokens, then that would be bad. The tokens aren't much use without your tokens too.
Only if the user revokes their authorisation.