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.
Related
First things firsts, I have my REST API "built with Express js" running on localhost:4000, and my react app running on localhost:3000.
So, when a user registers for a new account from the sign-up form in the react app, I send a POST request to the backend which generates an encrypted token and sends an email to the user containing a link with this format: http://localhost:4000/verify?id=<encrypted_key>.
The user clicks the link in his email which hits the /verify endpoint. Inside the verify API I decrypt the key and verify the user's email in the database -I'm using MongoDB- and then redirect the user to the react app to this route: http://localhost:3000/verified.
Everything works fine except when I visit http://localhost:3000/verified without being redirected to it like the case I said above.
Therefore, what I want is to guard this route so that I can view it only if I was redirected from the backend's API.
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 have creating a website running on Node.js and Express. For logging into my website I use passport.js based social login with Google, Facebook and Live.
I need to expose user data via authenticated REST services so that website's Chrome & Firefox browser extension can do CRUD operations.
When user clicks on a button injected via browser extension, I need to check if user is already logged in to website. If user is not logged in then I will do a redirect for login and return back to original page.
I am clueless after this. Which token do I use for REST API calls ?
Any Advice ?
After the social login, when the user is redirected to the callback url, you can create your own token, e.g. using uuid, and then send it to the client.
For all the consequent requests the client needs to use that token for authentication and you have to manage its expiration.
Yet another Facebook login question.
I am building a one page site that uses Facebook javascript authentication and login. I do not want any page reloads and want to users to login to Facebook at any time. Login to facebook will change my local views (using backbone.js) but shouldn't refresh the page. Although page is not refreshed I want to have server side (threw REST api) to "know" the uid of the user
I have used Server-side authentication before but wish to work only with client side authentication. (for various reasons)
Basically I follow http://developers.facebook.com/blog/post/534/ but my server is node.js
This is how I see the flow: (with restful API)
1. User enter site
2. FB JS SDK login/authenticate user
a. FB SDK has obtained access_token (valid for an hour)
b. signed request is saved in cookie data (fbsr_<app id>)
3. Browser issue any REST API call to Server
a. server looks into cookie to identify uid
Parse the signed_request
Validates sigend_request with application secret
identify uid from parsed signed_request
b. if needed to store long live access token
Server exchange code for tokenA
Server exchange tokenA for longed lived access token (valid for 2 month - fb_exchange_token)
Questions:
why shouldn't I move the access token from client to server instead of signed_request?
is this flow secure?
is it good practice?
Thanks
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)