ASP.NET MVC DotNetOpenAuth authorization server how-to - asp.net-mvc-4

I have this scenario: a corporate site (MVC 4) and a web shop; add OAuth 2 SSO functionality. Both sites have their own members, but the corp site (for which I'm responsible) must also work as an OAuth 2 authorization server and will store a web shop user id for each member. The shop requested the following endpoints:
Auth endpoint
• authorization:
…/oauth2/authorize?client_id={CLIENT_ID}&state={STATE}&response_type=code&redirect_uri={REDIRECT_URI}
• token
…/oauth2/token?code={TOKEN}&client_id={CLIENT_ID}&client_secret={CLIENT_SECRET}&redirect_uri={REDIRECT_URI}&grant_type=authorization_code
…/oauth2/token?refresh_token={TOKEN}&client_id={CLIENT_ID}&client_secret={CLIENT_SECRET}&redirect_uri={REDIRECT_URI}&grant_type=refresh_token
API endpoint
• getid (will return JSON with the shop id of the member):
…/oauth2/api/getid?access_token={TOKEN}
I don't have experience with OAuth, so I was looking at the DotNetOpenAuth samples and have concluded that I need to implement an OAuthAuthorizationServer, but modifying the sample to fit my requirements is difficult as it seems to do more and is complex.
As researching DotNetOpenAuth seems to be so time consuming, I'd like to ask: is modifying the OAuthAuthorizationServer sample the right approach? Or should I try to make a native implementation or try a different OAuth library that may be easier to use in my situation?
Please comment on my overall plan:
-keep the corp site member login flow standard forms auth, straightforward LogOn controller
-add an OAuth controller that will implement the three required endpoints as actions
-when the authorization action is reached, I validate the client and redirect to LogOn passing on the redirect_uri; I think the Authorize ActionResult from OAuthController.cs from the sample is where I should start investigating this, and return an AccountAuthorizeModel. Is this correct?
-after the user logs in, and if the login page was reached from the authorization endpoint, I redirect to redirect_uri with the code attached; I don't know where to start with this one. PrepareApproveAuthorizationRequest then PrepareResponse? Where does the code come from? Where in the flow should I add a new ClientAuthorization in the database?
-the shop will then use the code to get or refresh the token, from the /token endpoint; simply return HandleTokenRequest?
-with the token the shop site will be able to get the member data JSON; have to find out how to validate the token
Now, besides adding a Clients table to store the client ids and secrets, and ClientAuthorization to keep track of who's authorized, I don't know if the other tables from the DotNetOpenAuth sample are used and when: Nonce, SymmetricCryptoKey, User.
Modifying OAuth2AuthorizationServer.cs seems straightforward, I only have to add real certificates and make sure the clients are pulled from my data context.
Thanks!

I think you are right in most of the points. Let's comment them:
OAuth server should have 2 endpoints (not 3), as requesting token and refreshing token goes to the same endpoint (TokenEndpoint).
It depends if your are going to implement a different authentication server (or controller), or you are going to implement the authentication responsibility inside the authorization server. In case they are separated, the authentication server should be the one responsible of displaying the logon, authenticate and communicate with authorization server using OpenID protocol (Also supported by DotNetOpenAuth).
Once the user is authenticated, the authorization server should store the data of the user identity somehow, and return the authorization code (if using this Oauth flow) using DotNetOpenAuth functions:
var response =
this.AuthServer.PrepareApproveAuthorizationRequest(AuthorizationRequest,
User.Identity.Name);
return this.AuthServer.Channel.PrepareResponse(response);
finalResponse.AsActionResult();
I don't think you need to save nothing about the authorization process in the database, and the code is generated by DotNetOpenAuth and sent to the client into the query string of the redirection.
Then, the client should get the code (ProcessUserAuthorization) and call the TokenEndpoint. This endpoint is just returning HandleTokenRequest, that internally is calling to some OAuthAuthorizationServer functions, such as CreateAccessToken.
Once the client has the access token, it should call the resources, sending the token into the HTTP Header 'Authorization'. The resource server is the responsible to validate the token.
var resourceServer = new ResourceServer(new
StandardAccessTokenAnalyzer(signing, encrypting));
AccessToken token = resourceServer.GetAccessToken(request, scopes);
A store provider for nonce and crytoKeys is needed using this flow. Have a look to class InMemoryCryptoKeyStore in:
https://github.com/DotNetOpenAuth/DotNetOpenAuth/wiki/Security-scenarios
Hope this helps!

Related

How do I implement social login with GitHub accounts?

I've been asked by my employer to implement a log-in system for our web application using users' GitHub accounts. I've looked around online but I haven't been able to find a clear explanation of how to go about doing this with GitHub accounts (as opposed to with Facebook or Google accounts).
I just spent about a week's worth of effort figuring out how to do this, so I thought I'd write up an explanation to save future developers time.
The short(er) answer
You'll want to follow this guide in GitHub's docs ("Authorizing OAuth Apps"), with some additions (explained below) to allow it to work as a method of user authentication.
I implemented the "web application flow" for when our application will be deployed on our company's servers (where we can keep our company's GitHub app's "client secret" a secret), and the "device flow" for when our application will be deployed on our client's computers (because in that situation we won't be able to keep our "client secret" a secret).
GitHub's guide doesn't mention the steps below (because that guide is not intended specifically for implementing social login), but to get social login working I also did the following:
I created a users database table, with the idea being that each GitHub account used to log in would have its own corresponding row in this table.
Example users table schema:
id - INTEGER
email - VARCHAR
name - VARCHAR
github_id - VARCHAR
I created an oauth_tokens database table to store a copy of all of the GitHub access tokens that our back-end receives from GitHub.
This is needed to prevent other malicious websites from impersonating our users with valid GitHub access tokens generated by the user authorizing an access token for the malicious website.
Example oauth_tokens table schema:
id - INTEGER
user_id - INTEGER
access_token - VARCHAR
expires_at - DATETIME
refresh_token - VARCHAR
refresh_token_expires_at - DATETIME
device_code - VARCHAR <-- Used for the "device flow". I have the back-end send the
front-end the device code immediately upon starting the device flow, and I then
have the front-end poll the back-end with it until the back-end has received
the access token from GitHub, at which point the front-end discards the device
code and uses the access token as its authentication token.
I had the back-end send the front-end (the user) the GitHub access token for it to present with future requests as its authentication mechanism.
The front-end should store the token in localStorage if you want the user to remain logged in even after they close the browser tab they logged in with.
I added middleware on the back-end that--for each incoming request--looks up the provided access token in our database to see if it's expired, and if so, attempts to refresh it. If it succeeds in refreshing the token, it proceeds with the request as normal and includes the new access token in the response to the front-end in a custom response header the front-end is keeping an eye out for (I named it x-updated-access-token). If it fails to refresh the token, it aborts the request and sends a 401 response that the front-end takes as a signal to redirect the user to the login page.
Setting up your app to only allow unexpired access tokens to serve as a method of authentication is necessary to make it possible for the user to sign out of the application remotely from their settings page at GitHub.com.
I added front-end code to handle the saving / updating / removing of the GitHub access token, both to/from localStorage as well as to all requests to the back-end, as well as redirecting to a /login route if the front-end doesn't find an "access_token" localStorage variable set.
The code is further below if you want an in-depth explanation, but basically I used this article as a rough guide for how the front-end code should work for the "web application flow": OpenID Connect Client by Example - Codeburst.io
More information
To clarify some vocabulary: The goal here is to do user authentication via social login. Social login is a type of single-sign on.
The first thing you should understand is that--as of the time I'm writing this--GitHub has not set itself up to be a provider of social login in the way Facebook and Google have.
Facebook and Google both have developed special JavaScript libraries that you can use to implement social login without needing to write any(?) login-specific back-end code. GitHub has no such library, and from what I can tell it's not even possible for a third party to develop such a library because GitHub's API doesn't offer the functionality required to make such a library possible (specifically, they seem to support neither the "implicit flow" nor OpenID Connect).
The next thing you should understand is that--as of the time I'm writing this--GitHub's API does not seem to support the use of OpenID Connect to implement social login using GitHub accounts.
When I started doing research into how to implement social login I was confused by the fact that the most-recent online guides were saying that OpenID Connect was the current best-practice way to do it. And this is true, if the Identity Provider (e.g. GitHub) you're using supports it (i.e. their API can return OpenID Connect ID tokens). As far as I can tell, GitHub's API doesn't currently have the ability to return OpenID Connect ID tokens from the endpoints we'd need to request them from, although it does seem they support the use of OpenID Connect tokens elsewhere in their API.
Thus, the way web apps will generally want to implement social login with GitHub accounts is to use the OAuth 2.0 flow that most websites used before OpenID Connect, which most online resources call the "authorization code flow", but which GitHub's docs refer to as the "web application flow". It's just as secure but requires some more work/code than the other methods to implement properly. The takeaway is that implementing social login with GitHub is going to take more time than using an Identity Provider like Facebook or Google that have streamlined the process for developers.
If you (or your boss) still want to use GitHub for social login even after understanding it's going to take more time, it's worth spending some time to watch some explanations of how the OAuth 2.0 flow works, why OpenID Connect was developed (even though GitHub doesn't seem to support it), and become familiar with some key technical terms, as it'll make it easier to understand the GitHub guide.
OAuth 2.0
The best explanation of OAuth 2.0 that I found was this one by Okta: An Illustrated Guide to OAuth and OpenID Connect
The most important technical terms:
Identity Provider - This is GitHub, Facebook, Google, etc.
Client - This is your app; specifically, the back-end part of your app.
Authorization Code - "A short-lived temporary code the Client gives the [Identity Provider] in exchange for an Access Token."
Access Token: This is what lets your app ask GitHub for information about the user.
You may also find this graph helpful:
The slide title is "OIDC Authorization Code Flow" but the same flow is used for a non-OIDC OAuth 2.0 authorization code flow, with the only difference being that step 10 doesn't return an ID token, just the access token and refresh token.
The fact that step 11 is highlighted in green isn't significant; it's just the step the presenter wanted to highlight for this particular slide.
The graph shows the "Identity Provider" and "Resource Server" as separate entities, which might be confusing. In our case they're both GitHub's API; the "Identity Provider" is the part of GitHub's API that gets us an access token, and the "Resource Server" is the part of GitHub's API that we can send the access token to to take actions on behalf of the user (e.g. asking about their profile).
Source: Introduction to OAuth 2.0 and OpenID Connect (PowerPoint slides) - PragmaticWebSecurity.com
OpenID Connect (OIDC)
Again, GitHub doesn't seem to support this, but it's mentioned a lot online, so you may be curious to know what's going on here / what problem it solves / why GitHub doesn't support it.
The best explanation I've seen for why OpenID Connect was introduced and why it would be preferred over plain OAuth 2.0 for authentication is my own summary of a 2012 ThreadSafe blog post: Why use OpenID Connect instead of plain OAuth2?.
The short answer is that before OIDC existed, pure-frontend social login JavaScript libraries (like Facebook's) were using plain OAuth 2.0, but this method was open to an exploit where a malicious web app could have a user sign into their site (for example, using Facebook login) and then use the generated (Facebook) access token to impersonate that user on any other site that accepted that (Facebook) access token as a method of authentication. OIDC prevents that exploit.
This particular exploit is what people are referring to when they say "OAuth 2.0 is an authorization protocol, not an authentication protocol...OAuth says absolutely nothing about the user, nor does it say how the user proved their presence or even if they're still there.", which I saw mentioned over and over again while doing research on how to use OAuth 2.0 to implement social login, and which had me initially thinking that I needed to use OpenID Connect.
But GitHub doesn't have a pure-frontend social login JavaScript library, so it doesn't need to support OpenID Connect to address that exploit. You just need to make sure your app's back-end is keeping track of which GitHub access tokens it has generated rather than just trusting any valid GitHub access token it receives.
While doing research I came across HelloJS and wondered if I could use it to implement social login. From what I can tell, the answer is "not securely".
The first thing to understand is that when you use HelloJS, it is using the same authentication code flow I describe above, except HelloJS has its own back-end ("proxy") server set up to allow you to skip writing the back-end code normally needed to implement this flow, and the HelloJS front-end library allows you to skip writing all the front-end code normally needed.
The problem with using HelloJS for social login is the back-end server/proxy part: there seems to be no way to prevent the kind of attack that OpenID Connect was created to prevent: the end result of using HelloJS seems to be a GitHub access token, and there seems to be no way for your app's back-end to tell whether that access token was created by the user trying to log into your app or if it was created when the user was logging into some other malicious app (which is then using that access token to send requests to your app, impersonating the user).
If your app doesn't use a back-end then you could be fine, but most apps do rely on a back-end to store user-specific data that should only be accessible to that user.
You could get around this problem if you were able to query the proxy server to double-check which access tokens it had generated, but HelloJS doesn't seem to have a way to do this out-of-the-box, and if you decide to create your own proxy server so that you can do this, you seem to be ending up in a more-complicated situation than if you'd just avoided HelloJS from the beginning.
HelloJS instead seems to be intended for situations where your front-end just wants to query the GitHub API on behalf of the user to get information about their account, like their user details or their list of repositories, with no expectation that your back-end will be using the user's GitHub access token as a method for that user to access their private information on your back-end.
To implement the "web application flow" I used the following article as a reference, although it didn't perfectly map to what I needed to do with GitHub: OpenID Connect Client by Example - Codeburst.io
Keep in mind that this guide is for implementing the OpenID Connect authentication flow, which is similar-to-but-not-the-same-as the flow we need to use for GitHub.
The code here was especially helpful for getting my front-end code working properly.
GitHub does not allow for the use of a "nonce" as described in this guide, because that is a feature specific to (some implementations of?) OpenID Connect, and GitHub's API does not support the use of a nonce in the same way that Google's API does.
To implement the "device flow" I used the following article as inspiration: Using the OAuth 2.0 device flow to authenticate users in desktop apps
The key quote is this: "Basically, when you need to authenticate, the device will display a URL and a code (it could also display a QR code to avoid having to copy the URL), and start polling the identity provider to ask if authentication is complete. You navigate to the URL in the browser on your phone or computer, log in when prompted to, and enter the code. When you’re done, the next time the device polls the IdP, it will receive a token: the flow is complete."
Example code
The app I'm working on uses Vue + Quasar + TypeScript on the front-end, and Python + aiohttp on the back-end. Obviously you may not be able to use the code directly, but hopefully using it as a reference will give you enough of an idea of what the finished product should look like that you can more-quickly get your own code working.
Because of Stack Overflow's post length limits, I can't include the code in the body of this answer, so instead I'm linking the code in individual GitHub Gists.
App.vue
This is the 'parent component' which the entire front-end application is contained within. It has code that handles the situation during the "web application flow" where the user has been redirected by GitHub back to our application after authorizing our application. It takes the authorization code from the URL query parameters and sends it to our application's back-end, which in turn sends the authorization code to GitHub in exchange for the access token and refresh token.
axios.ts
This is most of the code from axios.ts. This is where I put the code that adds the GitHub access token to all requests to our app's back-end (if the front-end finds such a token in localStorage), as well as the code that looks at any responses from our app's back-end to see if the access token has been refreshed.
auth.py
This is the back-end file that contains all the routes used during the login process for both the "web application flow" and the "device flow". If the route URL contains "oauth" it's for the "web application flow", and if the route URL contains "device" it's for the "device flow"; I was just following GitHub's example there.
middleware.py
This is the back-end file that contains the middleware function that evaluates all incoming requests to see if the presented GitHub access token is one in our app's database, and hasn't yet expired. The code for refreshing the access token is in this file.
Login.vue
This is the front-end component that displays the "Login page". It has code for both the "web application flow" as well as the "device flow".
Summary of the two login flows as implemented in my application:
The web application flow
The user goes to http://mywebsite.com/
The front-end code checks whether there's an access_token localStorage variable (which would indicate the user has already logged in), and doesn't find one, so it redirects the user to the /login route.
See App.vue:mounted() and App.vue:watch:authenticated()
At the Login page/view, the user clicks the "Sign in with GitHub" button.
The front-end sets a random state localStorage variable, then redirects the user to GitHub's OAuth app authorization page with our app's client ID and the random state variable as URL query parameters.
See Login.vue:redirectUserToGitHubWebAppFlowLoginLink()
The user signs into GitHub (if they're not already signed in), authorizes our application, and is redirected back to http://mywebsite.com/ with an authentication code and the state variable as URL query parameters.
The app is looking for those URL query parameters every time it loads, and when it sees them, it makes sure the state variable matches what it stored in localStorage, and if so, it POSTs the authorization code to our back-end.
See App.vue:mounted() and App.vue:sendTheBackendTheAuthorizationCodeFromGitHub()
Our app's back-end receives the POSTed authorization code and then very quickly:
Note: the steps below are in auth.py:get_web_app_flow_access_token_and_refresh_token()
It sends the authorization code to GitHub in exchange for the access token and refresh token (as well as their expiration times).
It uses the access token to query GitHub's "/user" endpoint to get the user's GitHub id, email address, and name.
It looks in our database to see if we have a user with the retrieved GitHub id, and if not, creates one.
It creates a new "oauth_tokens" database record for the newly-retrieved access tokens and associates it with the user record.
Finally, it sends the access token to the front-end in the response to the front-end's request.
The front-end receives the response, sets an access_token variable in localStorage, and sets an authenticated Vue variable to true, which the app is constantly watching out for, and which triggers the front-end to redirect the user from the "login" view to the "app" view (i.e. the part of the app that requires the user to be authenticated).
See App.vue:sendTheBackendTheAuthorizationCodeFromGitHub() and App.vue:watch:authenticated()
The device flow
The user goes to http://mywebsite.com/
The front-end code checks whether there's an access_token localStorage variable (which would indicate the user has already logged in), and doesn't find one, so it redirects the user to the /login route.
See App.vue:mounted() and App.vue:watch:authenticated()
At the Login page/view, the user clicks the "Sign in with GitHub" button.
The front-end sends a request to our app's back-end asking for the user code that the user will enter while signed into their GitHub account.
See Login.vue:startTheDeviceLoginFlow()
The back-end receives this request and:
See auth.py:get_device_flow_user_code()
Sends a request to GitHub asking for a new user_code.
Creates an asynchronous task polling GitHub to see if the user has entered the user_code yet.
Sends the user a response with the user_code and device_code that it got from GitHub.
The front-end receives the response from our app's back-end and:
It stores the user_code and device_code in Vue variables.
See Login.vue:startTheDeviceLoginFlow()
The device_code is also saved to localStorage so that if the user closes the browser window that has the "log in" page open and then opens up a new one, they won't need to restart the login process.
It displays the user_code to the user.
See Login.vue in the template code block starting <div v-if="deviceFlowUserCode">
It shows a button that will open the GitHub URL where the user can enter the user_code (it will open the page in a new tab).
It shows a QR code that links to the same GitHub link, so that if the user is using the application on a computer and wants to enter the code on their phone, they can do that.
The app uses the received device_code to set a deviceFlowDeviceCode variable. A separate part of the code in the app is constantly checking to see if that variable has been set, and when it sees that it has, it begins polling the back-end to see if the back-end has received the access_token yet from GitHub.
See Login.vue:watch:deviceFlowDeviceCode() and Login.vue:repeatedlyPollTheBackEndForTheAccessTokenGivenTheDeviceCode()
The user either clicks the aforementioned button or scans the QR code with their phone, and enters the user code at https://github.com/login/device while logged into their GitHub account, either on the same device this application is running on or some other device (like their phone).
The back-end, while polling GitHub every few seconds as previously mentioned, receives the access_token and refresh_token, and as mentioned while describing the "web app flow", sends a request to GitHub's "/user" endpoint to get user data, then gets or creates a user db record, and then creates a new oauth_tokens db record.
See auth.py:_repeatedly_poll_github_to_check_if_the_user_has_entered_their_code()
The front-end, while polling our application's back-end every few seconds, finally receives a response from the back-end with the access_token, sets an access_token variable in localStorage, redirects the user to the "app" view (i.e. the part of the app that requires the user to be authenticated).
See Login.vue:repeatedlyPollTheBackEndForTheAccessTokenGivenTheDeviceCode()

API gateway and app backend authentication

I have application with backend and frontend. We are using JWT token for the authentication and Authorization(A2). Now we are planning to use express-gateway as an API gateway (AG) so that backend can be unload from routing and other protection heavy load and shift that burden to AG. Now since we are using AG shall we remove the A2 logic from backend and whatever request comes to backend (every request will be routed from consumer to backend via AG) we treat it as authenticated user and process the request, no need to verify again. If yes then we will still need JWT token to get the payload to extract the information like email id, role etc. For that should we pass the token from AG to backend. Also backed might have different kind of things on payload than EG. How to tackle that.
To pass authentication information on to a server, you need to use the request-transformer policy to add the information to the request headers going to the server, e.g. the following fragment adds a header named eg-consumers-firstname:
- request-transformer:
- condition:
name: authenticated
action:
headers:
add:
jscode: 'req.headers["eg-consumer-firstname"] = consumer.firstname'
The JS variables you can use in jscode sections is not particularly well documented, but you have access to everything in models/users.js.
In general, you can often adjust the gateway.config.yml such that scopes restrict which apiEndpoints (paths) are available to a given user; this is a better way to prevent unauthorized access then doing the processing on the downstream server side, which should do an independent check in case the API gateway has been compromised.

Authentication using Azure AD, failing at last step accessing Skype for Business

I am following this guide (https://learn.microsoft.com/en-us/skype-sdk/ucwa/authenticationusingazuread) in order to access Skype for Business. Everything goes fine till the last part but let's do step by step. I am building my .net console application to do this but in order to explain you properly the problem I am having I will show you directly the http calls through Insomnia (software used to make http calls).
Step 1:
GET request towards https://webdir.online.lync.com/autodiscover/autodiscoverservice.svc/root
I hit 200 and as answer I receive this:
Step 2:
I use the user link.
So I send an http request to https://webdir1e.online.lync.com/Autodiscover/AutodiscoverService.svc/root/oauth/user and I get a 401 Unauthorized (everything still correct).
In the header of the answer it points me to the Identity Provider to ask for authorization (authorization_uri)
Step 3: I use that link to authorize my app, which has its own client_Id (that I hide in the following screenshot).
This is how I compose the call:
If I send this http request I get redirected to the page where it asks my personal login and by inserting my credentials I succesfully login and hit 404, where in the answer I receive back my access token.
Step 5: I use the access token towards the same AutodiscoverService link of step 1. This is to register my application. I hit 200 and I receive back the link to access Skype for Business.
Finally (and this is where things go wrong) I send a POST request towards the applications link with the Bearer token, and I receive a 403 Forbidden. I think I am following correctly the guide but I can't figure out why I can access the resource at the last step.
EDIT:
The permissions are granted. I hide the name since it contains the name of my company. But it is the same of the domain of my login.
So the token you generated authorizes you to access resources at https://webdir1e.online.lync.com which you've done to fetch a new set of resources including the "application" resouce which is on a DIFFERENT host: https://webpooldb41e14.infra.lync.com.
You actually have to get another OAuth token now which authorizes you for the application resource and then you can POST to that to generate your session in UCWA.
As a side note... If you've defined your own single-tenant application in Azure that has been granted rights to SkypeForBusinessOnline then I think you should be targeting authorization and authentication endpoints of the form:
https://login.microsoftonline.com/{tenantID}/oauth2/v2.0/authorize
https://login.microsoftonline.com/{tenantID}/oauth2/v2.0/token
Also I should add, if you're trying to write a trusted secure client that users in your company will use I would suggest looking up the Resource Owner Password Credentials auth flow. It allows you to directly hit the token endpoint I mentioned above and exchange username/password credentials for an access token. Then you can manage auto-discovery and application creation easily under the hood without getting re-directed back and forth to Azure.
https://learn.microsoft.com/mt-mt/azure/active-directory/develop/v2-oauth-ropc

User authentication and login flow with Ember and JSON web tokens

I'm trying to figure out how is best to do authentication and login flow with Ember. I'll also add that this is the first web app I've built so it's all a bit new to me.
I have an Express.js backend with protected endpoints using JWTs (I'm using Passport, express-jwt and jsonwebtoken for that) and that all works.
On the client-side, I'm using Ember
Simple Auth with the JWT authenticator. I have the login flow working (I'm using the login-controller-mixin) and correctly see the isAuthenticated flag in the inspector after a successful login.
The thing I'm struggling with is what to do after login: once a user logs in and gets the token, should I make a subsequent call to get the user details, e.g. GET /me, so that I can then have a representative user model client side? These details would then let me transition to the appropriate route.
See this example in the repo for an example of how to add a property to the session that provides access to the current user.

OWIN/OAuth2 3rd party login: Authentication from Client App, Authorization from Web API

I am trying to create a Web API that allows the API's clients (native mobile apps) to login using a 3rd party cloud storage provider. I'm using the following general flow from Microsoft:
Here is what I am trying to achieve:
I am using the default ASP.NET Web API Visual Studio template with external authentication, along with the OWin.Security.Providers Nuget package for Dropbox login functionality, and the existing built-in login functionality for Google (Drive) and Microsoft (OneDrive).
The issue I'm having is that the built-in functionality all seems to do the authentication and authorization as part of one flow. For example, if I set up the following in Startup.Auth.cs:
DropboxAuthenticationOptions dropboxAuthOptions = new DropboxAuthenticationOptions
{
AppKey = _dropboxAppKey,
AppSecret = _dropboxAppSecret
};
app.UseDropboxAuthentication(dropboxAuthOptions);
... and navigate to this url from my web browser:
http://<api_base_url>/api/Account/ExternalLogin?provider=Dropbox&response_type=token&client_id=self&redirect_uri=<api_base_url>
I am successfully redirected to Dropbox to login:
https://www.dropbox.com/1/oauth2/authorize?response_type=code&client_id=<id>&redirect_uri=<redirect_uri>
... and then after I grant access, am redirected back to:
http://<api_base_url>/Help#access_token=<access_token>&token_type=bearer&expires_in=1209600
... as you can see the token is part of that, so could be extracted. The problem is that the client needs to be the one navigating to Dropbox and returning the authorization code back up to the Web API, and the Web API would send the authorization code back to the third party to get the token which would then be returned to the client... as shown in the diagram above. I need the ExternalLogin action in the AccountController to somehow retrieve the Dropbox url and return that to the client (it would just be a json response), but I don't see a way to retrieve that (it just returns a ChallengeResult, and the actual Dropbox url is buried somewhere). Also, I think I need a way to separately request the token from the third party based on the authorization code.
This post seems a little similar to what I am trying to do:
Registering Web API 2 external logins from multiple API clients with OWIN Identity
... but the solution there seems to require the client to be an MVC application, which is not necessarily the case for me. I want to keep this as simple as possible on the client side, follow the flow from my diagram above, but also not reinvent the wheel (reuse as much as possible of what already exists in the OWIN/OAuth2 implementation). Ideally I don't want the client to have to reference any of the OWIN/OAuth libraries since all I really need the client to do is access an external url provided by the API (Dropbox in my example), have the user input their credentials and give permission, and send the resulting authorization code back up to the api.
Conceptually this doesn't sound that hard but I have no idea how to implement it and still use as much of the existing OAuth code as possible. Please help!
To be clear, the sample I mentioned in the link you posted CAN be used with any OAuth2 client, using any supported flow (implicit, code or custom). When communicating with your own authorization server, you can of course use the implicit flow if you want to use JS or mobile apps: you just have to build an authorization request using response_type=token and extract the access token from the URI fragment on the JS side.
http://localhost:55985/connect/authorize?client_id=myClient&redirect_uri=http%3a%2f%2flocalhost%3a56854%2f&response_type=token
For reference, here's the sample: https://github.com/aspnet-security/AspNet.Security.OpenIdConnect.Server/tree/dev/samples/Mvc/Mvc.Server
In case you'd prefer a simpler approach (that would involve no custom OAuth2 authorization server), here's another option using the OAuth2 bearer authentication middleware and implementing a custom IAuthenticationTokenProvider to manually validate the opaque token issued by Dropbox. Unlike the mentioned sample (that acts like an authorization proxy server between Dropbox and the MVC client app), the JS app is directly registered with Dropbox.
You'll have to make a request against the Dropbox profile endpoint (https://api.dropbox.com/1/account/info) with the received token to validate it and build an adequate ClaimsIdentity instance for each request received by your API. Here's a sample (but please don't use it as-is, it hasn't been tested):
public sealed class DropboxAccessTokenProvider : AuthenticationTokenProvider {
public override async Task ReceiveAsync(AuthenticationTokenReceiveContext context) {
using (var client = new HttpClient()) {
var request = new HttpRequestMessage(HttpMethod.Get, "https://api.dropbox.com/1/account/info");
request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", context.Token);
var response = await client.SendAsync(request);
if (response.StatusCode != HttpStatusCode.OK) {
return;
}
var payload = JObject.Parse(await response.Content.ReadAsStringAsync());
var identity = new ClaimsIdentity("Dropbox");
identity.AddClaim(new Claim(ClaimTypes.NameIdentifier, payload.Value<string>("uid")));
context.SetTicket(new AuthenticationTicket(identity, new AuthenticationProperties()));
}
}
}
You can easily plug it via the AccessTokenProvider property:
app.UseOAuthBearerAuthentication(new OAuthBearerAuthenticationOptions {
AccessTokenProvider = new DropboxAccessTokenProvider()
});
It has its own downsides: it requires caching to avoid flooding the Dropbox endpoint and is not the right way to go if you want to accept tokens issued by different providers (e.g Dropbox, Microsoft, Google, Facebook).
Not to mention that if offers a very low security level: since you can't verify the audience of the access token (i.e the party the token was issued to), you can't ensure that the access token was issued to a client application you fully trust, which allows any third party developer to use his own Dropbox tokens with your API without having to request user's consent.
This is - obviously - a major security concern and that's why you SHOULD prefer the approach used in the linked sample. You can read more about confused deputy attacks on this thread: https://stackoverflow.com/a/17439317/542757.
Good luck, and don't hesitate if you still need help.