I'm building a Chrome Extension that connects to a .net 5 server for handling all the heavy works. It typically needs to call Google APIs, hence must be OAuth2.0 authenticated. Here is how I approach this:
First approach: Authentication in Chrome Extension
Use chrome.identity.getAuthToken to retrieve an access token in the service worker and pass it to backend server.
Backend server will then make API callsusing the served token.
The drawback of this approach is it won't work for the long-run background tasks in backend as the access token might be expired during the task and client's chrome browser is closed (hence, can't send a new token to the backend).
Second approach: Backend handles authentication
Make backend server handle the authentication and exchange for a new token upon expiration.
When chrome extension makes a request to backend, if the request hasn't been authenticated/authorized, backend signals back the url and extension redirects user to a new tab and asks user to sign in and to grant access.
There are some uncertainties about the second one:
How do we identify whether a request has authenticated by oauth2.0? (My guess is via cookie)
I've been following this guide https://developers.google.com/api-client-library/dotnet/guide/aaa_oauth but have not been able to authenticate on post request (when UI calling this).
I'm super new to this OAuth world. It doesn't seem like the JWT bearer token process.
Thanks in advance.
Related
We have a company building a web application for us and they want to authenticate using our existing website. I have written a login form that authenticates the user and needs to send back a token they can use for all future calls. At the moment I'm setting a cookie before redirecting back to their web app but I'm not sure if this is the way to go. Also, I need to test what I have built but not sure how to redirect to a login page and wait for that token response.
Token based authentication is stateless. You are not storing any information about your user on the server or in a session.
This concept alone takes care of many of the problems with having to store information on the server.
Although this implementation can vary, the gist of it is as follows:
User Requests Access with Username / Password
Application validates credentials
Application provides a signed token to the client
Client stores that token and sends it along with every request
Server verifies token and responds with data
More info here The Ins and Outs of Token Based Authentication
Here's an infographic to explain the process:
We have a webApi running under Asp.Net with Owin (.Net Framework 4.6).
Several native frontend clients (iOs, android etc.) are using that api.
That API currently uses Microsoft Login with bearer token and cookie authentication. This works, and the access token is returned directly to the webView in the client with the redirected requests and we are able to access our API with the Bearer token and another authentication cookie.
We have now the task to implement authentication with a LinkedIn auth provider in that API. For clearification: we need an OWIN implementation (no AspNet.Core).
We are able to get the access token from LinkedIn within the webAPI using this LinkedIn auth provider. So we see the token in our User.Identity.Claims. We are also able to return it to the client again. Yes, this is maybe no good idea, but it seems to be not possible to get the token directly in the browser/webView because the response_type=code is mandatory for linkedIn authentication. With response_type=token this works for the microsoft authentication.
Anyway at the end the webview is redirected to following url though we already have retrieved the access_token:
http://10.0.2.2:8108/signin-linkedin?error=unsupported_response_type
Please just ignore that we do not use https for now. The host is only for testing, but the important part is the appended error.
Why do we get this error? Who calls this request and why do we have that error though we have the token already?
Another information is, that the access token we have now in the client cannot be used for authentication against the webAPI. So we get back a 401 Unauthorized.
Maybe I should mention explicitly that we use also cookie authentication in the api, which seems to work as we receive the cookie in the webView and we are able to call methods that are protected with cookie authentication only in the correct user context.
Any help is highly appreciated!
The unsupported_response_type error is gone after using HTTPS.
I have a AngularJS Web Application that requests data from API written in .NET Web API.
Now, I have ADFS 3.0 OAuth configured with my client ID and redirect URL(https://www.someredirecturl.index.html) utilizing Authorization Code Grant Flow.
I also have a .NET Web API that returns some values.
For e.g https://www.example.com/showData
Whenever, i call the URL, the ADFS Login screen shows up.
Then, the browser is redirected to my Redirect_URL with the authorization code. For e.g https://www.someredirecturl.index.html?code=xxxxxxxxx
Then, i capture the code and send it to the ADFS server( POST REQUEST ) to get the token.
Now, i have the token.
After this step, i should be able to call my API https://www.example.com/showData with Authorization Code: Bearer + token.
But, how does it work without writing anything at the server side.
Do i have to read the headers with key Authorization, extract the token?
What is the best way to do this?
At any point, will i see data on the browser directly, or it will always be called by some program sending headers.
What if www.example.com is a website. and www.example.com/api is a resource endpoint. How to merge the two of them. can user login to www.example.com when he would enter his credentials on ADFS. How to redirect from Redirect_URL with authorization code?
Yes - as per this.
Basically:
Check that the JWT is well formed
Check the signature
Validate the standard claims
Check the Client permissions (scopes)
jwt.io has a number of libraries that do this for you.
I have been looking at using Open ID Connect as a third party authentication provider for a Web API application. The flow is as follows:
Users log in through UIWebView with iPhone application to the provider URL from https://daehwa.azurewebsites.net/api/Account/ExternalLogins?returnUrl=%2F&generateState=true
This redirects to my third party site which supports Open ID Connect authentication.
User logs in through this site and redirects back to my site with a token in the fragment of the URL in the form of #id_token=xxxxx
Looking at the following SO article: asp.net web api 2: how to login with external authentication services?
I then should be able to call /api/Account/UserInfo however this always returns 401 Unauthorized. Setting the Authorization: Bearer token doesn't seem to help either and always return unauthorized even when trying to call /api/Account/RegisterExternal.
Just to give you some more information about what I am trying to do I would like to either create an account or at least make subsequent OAuth calls to retrieve their email address and their display name ideally avoiding requesting this information from the user again. However for now I just want the authentication to actually work!
I would really appreciate any help anyone can provide. I'm new to third party auth and I feel as though I am missing something key. I think that my return url is the issue and my server needs to process this token and issue me with another one but not too sure.
Thanks,
Gerard
I looked everywhere for an answer about securing my webApi but always i'm pointed to OAuth or openID, but i don't want the user to login or authenticate. This is my problem:
I have a webapi which is called via Javascript to get the data in Json. This data is used in the Html of that page. (deployed on Azure)
Now i don't want someone else to get that data via Javascript or with a simple GET request. Only my html page is allowed to do so.
I'm looking for something to secure my Webapi to be only consumed by the applications i want. If i look to the OAuth and Azure stuff, people always have to login, but i want this page to be public, but only the webapi needs to be secure.
I can't check on IP, because the call is done at client side in the browser.
It is not possible to authenticate and thus secure the API to be used by a specific client (run entirely in the browser - like SPAs) app. You cannot protect the data the app sends to the API. (see for more details Protecting REST API behind SPA against data thiefs)
You could build some modules server side and then use some token based server to server communication if you do not want to introduce users and end user authentication.
Of course it is also a question of how you interpret security.
If it is just that you do not want other web apps to use the data -
CORS policies will do the job. It is unlikely that there will be more
than some isolated cases of users using a browser other than the
popular once which respect CORS.
If it is you do not want data to be mass downloaded you could
implement some client filtering based on IP. This could even be done
on the networking layer so the API do not need to be modified in any
way.
As a suggestion, you can have it secured making sure the request has some headers defined by you. For example, you can set an Authorization header with a token that only you know. You can for example, create a token based on a key that you and the webapi share, encrypt it with the time you are calling the api. The web api receives the request and:
1 - Check if the request has the token it requires;
2 - if it does, it creates a token the same way your page did;
3 - matches its token with the requests token;
If you are calling the webapi via javascript, the method may be exposed. However, it's one idea
Take a look to CORS (Cross Origin Resource Sharing), it may be your solution.
In synthesis you can allow requests to the Api only from some specific websites. Most, nearly all browsers, support it.
This is how you enable and configure it in Web Api 2.