Develop Reference

How to share auth0 authentication information between 2 different APIs?

Pretty much new on APIs and microservice world.
i am using auth0 for authentication.
I have a convert express API POST endpoint which will only work if the user is authenticated, however for frontend -> ( home page, login button, login from auth0 callback, redirection) I using different api Homepage express api.
After user logs in from homepage api, from his profile dashboard user tries to send a post request to convert API endpoint this doesn't work and throws an error check.state argument is missing.
How do I make sure if one API authenticates that authentication information should be shared with another API endpoint which needs authentication?
app.use(‘/authUrls’,requiresAuth(),authUrlsRouter) //convert api post request

This may be an assumption, but it appears that you are creating a regular web application with Node.js, and what you want is authentication per session, not per API endpoint. This quickstart from Auth0 walks through it nicely. It uses Passport.js and express-session to provide middleware.
As per the tutorial:
In a typical web application, the credentials used to authenticate a user are only transmitted during the login request. If authentication succeeds, a session is established and maintained via a cookie set in the user's browser. Each subsequent request does not contain credentials, but rather the unique cookie that identifies the session.
How it works: when the login api is called and completed successfully, the user's authentication is stored in that session. Whenever other API's are called that require an authenticated user, you can just include the middleware (in the quickstart it is called 'secured'): it will query that respective session's data and allow / disallow based on the user's authentication status.
For example, the convert endpoint:
router.post('/convert', secured(), this.convertfunction);
And a non-auth endpoint:
router.get('/other', this.otherfunction);
The full tutorial has much more information available. But this illustrates how middleware will solve your problem.

Managing redirects to a subdomain after authentication in a React/Rails application using React Router

I have a React single page application using React Router that hooks into a Rails 5 API. The Rails application uses devise_token_auth for authentication. I've successfully created an authentication process that stores the user state in a Redux store on the client side.
Each user of the application belongs to a company. Each company has its own unique subdomain (e.g., companya.foo.com, companyb.foo.com). A user should be redirected to their company subdomain after signing in from foo.com. All requests for an authenticated user should keep them on their own subdomain. Users should be redirected back to foo.com when they sign out.
I read that this is impossible with React Router and the browser API but there has to be a way to achieve this. I also saw some .htaccess suggestions but I am unfamiliar with this approach and I'm not sure if this will handle dynamic redirects.
What is the most intuitive approach to solve this problem?

You would need to redirect to the subdomain and pass the authentication token in the params to keep the user logged in

node express react oauth pass access token after athorization in callback with react client app

I have a node server that authenticates with a third party (like stack overflow does) using oauth. When the third party hits my callback and I authorize the request and get the access token and other info, I want to then pass this info to a react app I made, so then the react app can make REST calls to using the access token straight from the provider.
I am new to react and node, but am able to make a node server that can get the access and refresh token info. I am new to 'serving' and serving a react app. I have been serving using
app.use('/client', express.static(__dirname + '/client'));
to serve react apps, and this works great to a limited extent. The situation I am currently in exceeds the extent and I want to learn how to send the oauth info along with my react app back after authorizing in the callback. The flow I am using authorizes the request in the callback and then does a redirect back to the /client route to render the app, which fails to pass any oauth info to the client. Is there any way to set the header before that redirect to have the oauth info, and then some how get that oauth info in the react app?
I am posting here to get some advice on some avenues and resources I should read up on, and maybe some suggestions for my current situation. I am eager to learn more on express and am currently looking to set the header with the info I need and then serving the react app as a file or something, I am not sure yet.
Thanks to all in advanced!

I'll give my best to answer your question. So the problem with SPA(Single Page Application) and OAuth login is that the only way to transfer data with redirects is URL query string. The JWT(JSON Web Token) would allow this, but it's only supported in mobile native SDK-s. Solution for the web, without using the popover flows here:
For Node.js I suggest to use Passport.js OAuth modules, the login flow:
Example /auth/google -> redirect to Google login page.
On success, you get redirected back to callback url /auth/google/callback
You also get back the access_token, refresh_token, basic profile information etc.
No sessions are used so we use the JWT and generate the token on server side.
Redirect back to application with the token: app.example.com?token=JASJKDk..
On client side extract the token from query string.
This is just one possible flow that you might use, instead of JWT you could also use session/cookie solution.

OAuth 2.0 Implicit Grant Type with AngularJS frontend

I'm currently building a frontend client for my own Apigility API.
The API uses OAuth 2.0 Authentication which is working fine.
I want to create an AngularJS Landingpage to let the users authenticate by entering their credentials. Because the Client is created with JavaScript,
I shouldn't save the client_secret in the Client, correct?
I have read a lot of posts, but still haven't the right solution.
Is it correct to use the implicit grant type for this scenario?
This procedure is working, I'm being redirected to the authentication server,
after the client authorization and entering credentials, I get back to the client (authenticated).
But I don't want to get redirected to another authentication page.
Is it also possible to authenticate directly and secure on the angularJS frontend?
Thanks,
Simon

You should take a look at this post i made:
https://stackoverflow.com/a/42443878/2963703
It details how to do this using the Spotify API. Your page won't get redirected, instead a popup window will open in which the user authorizes themselves. Once they're authorized the window will close itself and in your main page you will have the access token you need.

Firebase in Cordova/Phonegap: Log in using Email/Password from within app?

I'm running a webview from a cordova app and want to authenticate a user, I know they have the OAuth strategies but I need to use the email/password combination.
I'd like to keep things simple but may end up having to generate a token.
Open an InAppBrowser that loads an auth flow for firebase
Listen for that auth flow to be completed using this method: http://blogs.telerik.com/appbuilder/posts/13-12-23/cross-window-communication-with-cordova%27s-inappbrowser
Grab the result from the webview again and insert it into the webview firebase instance
I'm guessing that's not possible due to security.
My app is using Amazon login (required) so my alternative would be:
webview loads InAppBrowser with our external url
that loads Amazon auth, then generates a token for Firebase
webview listens for token and grabs it, stores it in localstorage
Edit:
In the firebase docs on logging in with a username/password, I see it returns a token for the session and more information in the authData object:
https://www.firebase.com/docs/web/guide/user-auth.html
Could I then take all the information from that object and send it back over to the cordova webview and then populate that Firebase ref with the information?

Some answers from the wonderfully helpful support at Firebase:
First:
You’re correct – anyone can make a request to sign up, and we don’t expose any capability to secure the url which people can sign up from for email / password authentication.
The main reason that we require / enable origin whitelisting for OAuth authentication, but not for email / password authentication, tends to revolve around sessioning.
The Firebase login server does not maintain sessions (via cookies or any other method), and so requests to the login server for password auth. requires a user credential (the password) for every request. CSRF is typically a risk when a malicious party can take advantage of a user’s session browser, i.e. make requests on behalf of the user to some page where cookies are automatically sent by the browser.
Furthermore, we don’t have a great way to actually do ideal origin-based whitelisting for these pure HTTP requests. We could use CORS, but would have to fall back to JSONP for older browser environments that don’t support it. To complicate matters further, PhoneGap / Cordova apps don’t have the same notion of an “origin” at all, and from the perspective of a server – the calls are indistinguishable from any malicious party making an HTTP request with the same headers.
The OAuth providers, however, use cookies for sessioning and do not require user invention for each auth. request. If you’ve approved a particular Facebook app, you won’t be shown any UI/UX or be prompted the next time that app requests your data – it will be invisible. When we do OAuth, we never have to send any user credentials to Facebook / Twitter / etc., because those are stored in browser cookies for facebook.com / twitter.com / etc. What we need to protect is a malicious party pretending to be a popular, valid Facebook app. and taking advantage of that short-circuit behavior that would get access to user data without the user’s knowledge.
My response:
So, how is that secured? If anyone can make a request to sign up from a
cordova webview (which comes from no specific url, just the app iteself)
then I can't secure from which url people can sign up from? So any site
could use our url "xxx.com" in their config and start registering
users?
That doesn't seem right to me.
I think I still need to have an external url that is whitelisted by you
guys. That would have the login form and do the auth.
But then my question is, can I transfer that auth back to my cordova app?
Is it somewhere in localStorage I can check? I'll have to run some tests.
And final response:
Sure thing – we’re happy to help. I wrote much of the original client authentication code, and can speak to the design decisions and rationale that went into it. Be sure to let me know if you have further questions there.
While we don’t store user passwords in cookies, of course, we maintain a Firebase auth. token in LocalStorage. Our authentication tokens are signed by your unique Firebase secret (so they cannot be spoofed), and can contain any arbitrary user data that would be useful in your security rules.
By default, and when using the delegated login (email + password) service, these tokens will only contain a user id to uniquely identify your users for use in your security rules. For example, you could restrict all writes or reads to a given path (e.g. write to /users/$uid/name) by the user id present in the token (“.write” = “$uid = auth.uid”). Much more information on that topic available on our website.
Your plan to spin up a server to authenticate users with Amazon and generate tokens sounds correct. This is a common pattern for our users who wish to use authentication methods that we don’t support out-of-the-box (ie Amazon OAuth) or have custom auth requirements. Note: once you’ve created those tokens and sent them down to the client, they’ll be automatically persisted for you once you call ref.authWithCustomToken(…). Subsequent restarts of the app will use the same token, as long as it has not yet expired.

This is a topic of interest to me too as I have implemented something similar , twitter digits (native android) + firebase custom login in webview.
I think, as recommended by firebase, you can use other authentication providers and then the firebase custom login.
Do you use the Amazon login in android native code ? If so after login, then generate a JWT token for firebase and use it to access firebase.
If all code is in Html/js app, then maybe you can use custom login and generate a token on your server after making sure its logged in to the Amazon.
The trouble with Android hybrid apps is the following: the JWT token (for firebase) should be created on secure system (eg. server side) not with android java code, other option for hybrid app is to do a http request to generate the token, but I find that less secure, anyone would be able to get a token by finding the URL, than I resort to generate token within android app code, you can change security key/seed for token when doing new releases.
In summary, I don't think firebase studied the problem of mobile hybrid apps.