I'm using Google's Java Client for server-side JWT authentication, along with their HTML snippet for the frontend. I'd like to do some testing locally to make sure my user flow works - but I'm not able to get my JWT from the frontend sign-in steps.
https://developers.google.com/identity/gsi/web/guides/display-button
I've entered my correct client ID, but I think it's upset that I used localhost:3000/login as the redirect route. Does anyone know how to set this up for local development?
[GSI_LOGGER]: The given origin is not allowed for the given client ID.
I tried to fetch my actual JWT using the Google Sign In HTML snippet. I expected this to work fine, since it's my actual google account and a legitimate client ID.
Related
We currently have a website that is setup to use SSO through Azure AD. it is configured to with SAML.
Yet, we have third application that needs to connect to this website using specific email and password.
This application can do any default connection that POSTMAN can do.
What I do notice is that web all cookies are removed from the browser. the website allows me to enter
the email address and password.
I am trying to configure POSTMAN to test login to this website. And using the POSTMAN configuration i will be able to configure the application.
Any Guidance is greatly appreciated. Thank you!
I have try configuring post using HTTPS POST BASIC Authentication. Not sure if this correct manner as I am not postman expert nor have attempted such authentication method before.
Our expectation is the POSTMAN could login into the website and create a cookie that has an active session.
Postman is not a browser so it doesn't "log in". The authentication in Postman is related to webservice calls. So imagine you have an online shop and you expose your API to a third party (let's say a sponsor or partner). For example you let another site (the partner/sponsor) add items for your common client from his site (instead of him having to logout of that site then login to your site, it's easier and your partnership makes both sites profitable, let's say for our example - so their site would be more like a sort of forwarder - when the user adds an item on the partner's site, they actually add it in the cart on your site).
In our example, they would call your API (for example, adding an item in the cart). The question is, how do they do that? How do you stop abuse from a malicious user? Simple: you add authentication. So what your (theoretical) shop's partner does is use some auth method (as you said, Basic Auth) to call the endpoint that results into adding an item into the cart for purchase.
But this auth is not what the client uses to log in to your partner or your site. It's an internal auth, like a sort of a "technical" user. And what you would do in Postman is simulate that call and the Postman login would be to allow it to call endpoints.
If, on the other hand, you have a separate login call that this is all it does, logging in, then yes, you can use Postman to login, BUT, keep in mind that the login auth info would not AND SHOULD NOT be the same as the API call login info. So you would still use an auth to allow the API call and a (hopefully different) auth for the actual login url as params.
In other words, Postman auth in any POST or GET call is just a way to tell the remote server they can trust you because you identify yourself. A login window like the Microsoft one is one for user accounts which is something totally different.
Before my question, it's important to note that the app I'm working with has been given to me pre-built with little documentation. Long story. I've never worked with a serverless application before, hence my complete confusion.
Here's some context:
I have a serverless application: React app that sits in a S3 bucket, being served by AWS CloudFront. It uses Auth0 for authentication. Currently, the logic is, if a user tries to visit the app's domain, Auth0 pops-up with a login prompt. The user enters their credentials which is then sent to an AWS Lambda function, which exchanges the confirmed login credentials for a JSON web token. This is sent back to Auth0 which then redirects the user to the app's domain (Please critique this explanation if you think I've misexplained something).
I'm trying to test Auth0 locally so that I can access the roles I've assigned to each user to eventually serve that user data specific to their role.
Problem:
However, I'm unable to test Auth locally. When I run npm start at localhost:3000, I'm taken straight to the main page, skipping login entirely.
I understand this could be because of numerous things, but here's what I've tried.
I've gone to my Auth0 dashboard, and under Allowed Callback URLS, i put http://localhost:3000/logincb. (logincb is the callback given during the AWS Lambda step).
I tried using ngrok to create a secure connection and then putting this url in Allowed Callback URLs, still no Auth0 pop-up on localhost.
I tried putting in conditons in the Lambda function if the request url is localhost:3000 i.e do the exact same thing as you would if the request url was the app's domain name
I can post the Lambda function if that's helpful. It's similar to the examples given on AWS Lambda's docs for example functions when using Amazon CloudFront. It has functions for handling cookies, webtokens, post request to Auth0, etc.
I apologize for the vagueness of the question, I just need some inspiration/ideas at this point.
Peace and love
I created this web app completely in go-lang, which uses Google Drive API to authenticate users. Once user authenticated, it saves the token in a <user-email>_token.json file so the app can operate for 24 hours without the users involvement. It works fine. But now I want to separate the front-end from (Go-Lang)back-end and convert it to AngularJS.
So I have this problem with authentication. Because I should keep the authentication in server-side. But then how would Angular know that the user is authenticated or not? Because I cannot use sessions.
Should I need to use JWT to this? If it is, then how should I do it?
Your token does not have to be on the server side.
Why? Because if you have many clients connected to your server, it would mean that all of these clients are sharing the same token and therefore have access to the Google Drive linked to this token. It does not make sense.
The token has to be on the client side. You should save the token as a cookie, maybe by using JWT, I let you read the documentation of JWT to know why it would be interesting to use it in your case or not.
Then on your Angular, you have to say something like "hey, this client has a cookie called "my-google-drive-token", let's check if that is a good one... Mmmmh, okay seems to be good, I display the Google Drive content".
Think about using good practices about security (using an encrypted token in your cookie, making the connection between the front and the back safe, keep your API key safe...).
Your backend is only a gateway between your front-end and the Google Drive API.
Also, check the usefulness of your server. I think that in your case, a simple frontend connected to the Google API is enough.
my ignorance is shining brightly on this one. I have a Web App that uses the MEAN stack (Mongo, Express, Angularjs, Nodejs) and some of the functionality is lackluster on mobile devices. So I'm developing a mobile version of the app on the Appgyver Supersonic platform. The Appgyver framework is based on an Angularjs front-end.
So I was hoping to just use the same Express/Nodejs server that I have running for the Web App and make queries/requests from the mobile app. Authentication is my current challenge. I assumed that I could send the username and password via a POST request and sign in and create a new session. I can sign in but I can't get access to the session cookie connect.sid so my next request has no session data with it.
TLDR; I have an Angular app that is on a different server than my Express/Nodejs back-end. I wish to authenticate the Angular app but can't figure out how to access the connect.sid cookie.
Since this never got any traction and I found what I think is a 'workable' solution I figure I'll answer my own question. If you see that I'm doing something really stupid here, please let me know.
When I login my client to the server, I respond with a session token. I store that same token on the User profile in Mongoose. I store the token on the mobile device using localStorage.
Whenever I send a request to the server I send the token with it, and have the Server check to see if the token matches the User token - if it does, I grab the User Profile data and assign it to req.user; which then seems to make the back-end operate properly.
Any major security concerns?
I'm plan on deploy a Java application to Google AppEngine and use federated login (still experimental according to Google). The application is pretty simple Java EE application which expose RESTful interface for simple CRUD operations.
I then want to be able to authenticate to this application using Windows Client Application written in C#.
I think the application should be able to open a window with a browser in ti which will present the login page of my web application and after successful authentication I should be able to get the login token or a cookie to use in the rest of my HTTP requests.
Is it possible to do such thing using federated login? I've found a post explain how to do it using google proprietary login.
Thank you,
Ido.
I've manage to make this work much easier then I thought it would be.
When I send HTTP request to my web service I get 302 Found response with response header name Location which point to the login page.
I use WebBrowser control, register to it Navigated even and navigate to the URL in the Location header.
When the Navigated even fire I use the code from this answer to get the cookies container.
I check each cookie until I find one with the name ACSID and store it.
For every web request to my service I add cookie name ACSID with the value saved at step 4.
This is not the most secure way of doing this. I will add check for the domain of the cookie but this looks good.