I am writing an API to be used by both my JavaScript app (same domain, API is at api.example.com and site at example.com and 3rd party developers (mobile, desktop, etc). Now I want to use OAuth but I have no idea how the workflow is when using both OAuth and using my application with the same origin policy.
How do I authenticate the user in my web app? When I send the username and password, can I check if the request came from my domain and then return the token? The token will be stored in a cookie and sent back to the server on every request. So there are 2 parts:
If the request came from my domain, just check for token else throw HTTP exception.
If not my domain, do OAuth authentication.
Is this possible? How do I go about setting this up in asp.net web API? (mainly the part about checking if the request is in the same domain)
I am guessing that to log into your web app you're not using OAuth, but simply accept username and password and start a session? If so you don't really have to bother with OAuth for your own site.
Set up the session cookie to be valid across *.example.com and you should be able to validate that cookie both on site.example.com and api.example.com.
Example:
Request comes in to api.example.com/verify_credentials.json
Serve response if OAuth validation is successful.
If not, attempt Cookie validation - serve if successful
Return 402 Unauthorized if both fail.
Here's a thread about sharing a cookie across sub domains: ASP.NET Subdomain Cookie (parent and one subdomain)
Related
I am building a web app in which I have implemented Oauth using GitHub.
when user clicks sign in with Oauth, user is redirected to GitHub for sign in and authorization
and when authorized again redirected to the the callback path(Auth server) with access token in parameters.
using access token when I get needed information from GitHub I want to send information cookie to the frontend domain but when I send cookie, it is getting stored to auth server domain instead of frontend domain on browser.
frontend-(redirect)->GitHub Oauth-(redirect)->Oauth server send cookie and redirect to frontend
I want frontend to have cookie which will have user info.
Since local storage and session storage are both accessible via JavaScript it is best not to store the authentication JWT in either of them to avoid XSS attacks.
Since OpenID connect 2.0 is performed on a separate domain how do we set a server-side HTTP only cookie that contains the authenticated JWT?
My guess is this:
The user goes to your website then clicks sign-in.
The user gets redirected to the 3rd party OpenID connect 2.0 provider.
The user signs in and is now redirected to the route of your choice www.example.com/myredirectlogin.
The user's browser then makes a get request when the redirect lands on my route and it passes in the JWT token in the URI.
The server then validates the JWT via Asymmetric algorithm with the public key given by the provider.
The server then returns a server-side HTTP only cookie with the JWT as the value and the client-side doesn't have any recollection of the JWT since it was only in the URI and isn't stored anywhere else.
My question is: Is the above the correct process to securely handle OpenIDConnect 2.0 flow?
I'm assuming you mean the "Id Token" when you say "authentication JWT", since that's the only JWT required by OpenID connect.
All the flows that OpenID connect supports are listed in the spec. If you want to log in to the authorization server and authenticate to a separate site, then you will often use the "authorization code" flow which doesn't send the ID token to the browser at all. There are other flows defined by OpenID connect, but none of them mention storing the ID token in a cookie - how the session is maintained between the client (the site you're authenticating to) and the browser is a separate issue from authenticating the user.
I found the answer within authorization code flow: https://connect2id.com/learn/openid-connect
List of steps
OAuth 2.0 and OIDC Authorization code flow
The user hits your website's login route
The user is redirected to an identity provider with a proper tenant id
The user is authenticated and is redirected to your callback route with an access token in a query parameter i.e. &access_code=234234sdfkljsak.
a get request is executed on your web server at the callback route with the access token in the query parameters.
this callback get route should then make a post-call to retrieve an actual JWTidentity token from the provider i.e. azure b2c and it will add the access token as part of the request either as a query parameter or post of body.
the provider (Azure B2C) then will respond with an identity JWT token that we will send back to the user's browser as an HTTP-only session cookie that way the user is now SSOed among all browser tabs and the cookie will be sent with every request automatically and is protected from xss.
I am working on an app for some company, but I have some problems with the security measures in combination with the Azure ADAL library.
For security reasons they setup a ADFS authentication server with the guys of microsoft. So that my webservice can only be accessed by a token given by the authentication server.
I use the adal library to get this authentication token and inside the network I have no problems with accessing the webservice.
For outside the network, I need to go through the proxy, this using a reverse proxy. For authentication on the reverse proxy you also need to authenticate to the ADFS authentication server.
Here is an image to explain it a little bit better :)
For the inside phone
Send authentication request to the adfs authentication server.
Get back a authorization token.
Send a request for data to the webservice with the authentication token
For the outside phone
Send authentication request to the internal adfs authentication server. This needs to pass through the reverse proxy.
The reverse proxy sees that you are not authenticated and will first authenticate with the external adfs authentication server, before he will let you pass through.
This authentication will add a cookie inside the httpclient so that it knows the request is already authenticated.
Now it will request the authentication token, and because it has the cookie inside the request, it will not need to authentication anymore.
It will return the token to the phone.
I am now trying to request some data from the webservice, with the token in the request. But inside the Azure ADAL library I cannot get access to the cookie to add this to the request to pass me through the Reverse Proxy. So the reverse proxy will block me an instead of a data response I will get the login page from the reverse proxy back as an html string.
So the problem that I am trying to address is that I cannot get access to the cookie inside the Azure ADAL library, or is there any other fix I didn't seeing.
We have a web service, which currently uses Basic Auth over https to authenticate user requests. We also have a website which uses the service, and a native Windows client, which also uses the web service. I've read about OAuth, and it seems like it's always used for giving or getting access to external resources, i.e. delegation, but I'm trying to understand if it's a replacement for Basic Auth.
I'm not quite sure how all the parts fit together. Do you use Basic over https to the website to retrieve a secret and then have the javascript which is making requests to the REST services authenticate to the web service using OAuth instead of Basic?
It seems that at some point the user needs to enter their username and password into a form. I'm not sure what typically happens next. Is this even a use case for OAuth?
If you have local database accounts for the users (Resource owners) then you can replace the basic authentication with the one of OAuth flow named "Resource Owner Password Credentials" flow.
It is very simple flow where you issue HTTP post to an end point specified in your HTTP server usually named /token The content-type for this HTTP Post action is x-www-form-urlencoded, so the post body will contain something like this grant_type=password&username=Taiseer&password=SuperPass
One the request is sent to the /token end point the server will validate the user credentials against your database store, and if all is valid it should generate a token (signed string) which contains all the claims for this resource owner (user). Then your client application should present this token in the Authorization header with each call to any protected end point using bearer scheme.
This token expires after certain period and you can configure this from the AuthZ server. You can read my detailed blog post Token Based Authentication to get more details.
I am using .htaccess authentication for my website. Once the authentication happen with AD vi LDAP, how the authenticated user's session and cookies got created in the browser and where the redirection is really happening to my website. Please help in this or please share any links which explains this process.
Take a look at the wiki pages for BASIC authentication and DIGEST authentication, both is an authentication mechanism that is on the protocol (HTTP). Basically, this is what the browser sees (heavily paraphrasing here):
Attempt to request a URI, webserver replies with a 401 response and a WWW-Authenticate header
This header contains a REALM, kind of like a group of pages that all belong to the same authentication realm
Browser pops up a modal dialog box asking for a username and password.
Depending on BASIC or DIGEST, that password is sent back to the webserver along with the original request that resulted in a 401.
If the credentials are incorrect, a 403 is returned and the browser shows an appropriate error message. Otherwise, the webserver returns the requested page.
The browser knows this URL belongs to the REALM, so every time this URL is requested, authorization is automatically sent along with the request.
If the browser requests something else that also requires authentication, and it belongs to the same REALM, the browser will automatically send the authorization when the webserver returns a 401 and the REALM.
How the webserver is configured with REALM info and a list of credentials varies. It could be hooked up to a LDAP database, Active directory, a flat file with hashed passwords, etc.
This is different than cookies or other webapp-level authentication because it doesn't use the HTTP protocol to authenticate. The webapp has a page with forms for a username and password, those are sent via a POST/GET request as parameters, and it's up to the webapp to determine if those credentials are valid. If they are valid, the webapp could choose to store a session ID as a cookie so the browser can continue to browse pages served by the webapp.
One of the end-user differences between this and HTTP authentication is that the webapp can delete the cookie, or invalidate that session, essentially logging the user out of the webapp. This isn't really possible with HTTP authentication because the browser blindly submits an authorization header when requesting pages under the same REALM. One way to get around this is to make the webserver forcefully return a 403 when a protected page is requested.
Another difference is that with HTTP authentication, you can include a username/password as part of the URL. How does http://user:pass#host.com authentication work?
Also see: http://blog.distributedmatter.net/post/2008/06/09/HTTP-authentication-mechanisms-and-how-they-could-work-in-Restlet for a more complete description of authentication in general.