I have client-side login on my app which is working just fine. Now I need to pass the clients UID to Node.
Found this Verify ID Tokens in Firebase docs, but i just don't know how would i actually do this part: "Send token to your backend via HTTPS"
Does your Node server-side piece have an API already created, or do you need to build that?
There are many ways to pass this information from the client to the server. Sometimes auth information is passed in an HTTP header of an API call that does something else. Sometimes APIs include a specific call to "register" a user with the backend, where you would pass the client-side token to the server in the payload of that one call.
There is no single best way to pass the client user authorization information to the server, every application needs to make that decision as part of their server-side design.
Related
Let's use this picture as a demo
So I have 2 node apps. One is where I have the login pages etc., and 2 is the API server with JWT as security layer.
Currently, the first server is only for rendering client pages. I have a login page, and the route where the login process goes is in the server with JWT.
My problem is that I want to check my token if it's valid before rendering the login page. So I must do that in the first server.
What is the proper way of doing this? Can I install express session in my first server to store the token from the second server? In that way, I can send a request from the first server to the API server before rendering client pages.
I'm building a vue js web app and I would like to make respective calls to the to my prismic repo, but I don't know how to do it without exposing my access token. I am using the rest api approach shown here.
Any ideas?
The http request syntax is as follows. I want to do this inside my vue components while not exposing the access_token.
http://your-repository-name.prismic.io/api/v2/documents/search?ref=Your_Ref&access_token=Your_Token
In my API/Security settings I'm also given a Client ID and Client Secret. I can't figure out how I can use these either.
Thanks
You'd have to store your access token on your server and make it process the requests on behalf of the client.
In the end, you'd send requests to your server instead of directly to prismic.io, your server will then send the access token authorized request, fetch whatever you need and return it back in response to the client.
The work flow would look like this:
Client sends request to i.e. http://localhost:8000/api/endpoint
Server sends request to prismic.io endpoint associated with the above endpoint.
Server gets prismic.io response and sends it back to the client.
Client gets the response.
If you want to hide your access token client-side, then it's impossible. To protect your access token the other two options are:
Make users use their own prismic.io access tokens.
Allow access only to authorized users.
The two options above are probably not what you want, so setting up a proxy server is what's left.
I am looking to connect to a secure REST service via Angular and have found the official way to do this is to set the authentication ticket as follows:
$httpProvider.defaults.headers.common['Authorization'] = 'dhfkssksk';
However isn't this insecure as anyone can simply view the JavaScript and find out the auth code?
If you mean that your client app is connecting directly to your backend api (i.e. no 3rd party services), then the short answer is yes.
However, there are a few considerations you need to take into account:
You must only send this ticket to your backend and nothing else. I.e. set an HTTP filter in angular that acts on every client-side request and only sends this Auth header if the URL matches your API url.
You need to use SSL, to protect the token during transmission.
I would to ask a few questions to better understand some procedures. I'm trying to write a web api project which will be a backend for both web and mobile clients.
The problem that i've in mind is about security. I don't want to use Identity or any other providers. I want to use my own database user and role structures.
Only authenticated client applications should be consuming my application. So that anonymous applications should not consume it.
So what should be the approach ? I 've written a custom AuthorizationAttribute and check some custom headers like "AppID","AppSecurity" key which i store in my own database and if the client sends the right appId and the key it means the app is authenticated to consume the API which does not sound very secure to me.
Another issue is that ; Lets say i've developed a javascript web application and i've to first authenticate the application itself before making GET/POST/PUT/DELETE etc requests which means i've to add some kind of authentication data like username, appkey, password in one of the js files for sending the "AppID" and the "AppSecurity" keys in the header. A client who knows how to use some developer tools or fiddler can easily capture my header values that are being sent to the server side? Even if i pass authentication values on the body of my json request it still can be found on the js files that are sent to the client. I'm also confused about that tooç
So basically i want to build a server side api that will serve the data and get data from the authenticated client applications only. What i need is a simple example for that without using any identity providers.
I have separated projects,
Server side node.js with express to serve restful api but returning JSON instead html. All the examples in internet are returning html with ejs.
Frontend is and independent application with backbone and socket.io.
I want to do a login and registration page and I did it with passport.js on the server side, but I have not idea of how to send the token to the frontend and store it there to send It on every request to the server. If the user is out of session then the login page, ,must be shown.
I want a way compatible with oauth 2.0 for multiple authentication strategies.
Sorry for my English and I have a lot of dudes and I don't understand all the concepts.
Basically what you have is an API and a client, and you need two things:
The client to be able to open a session on the API.
The client to be able to embed its session credentials in every request so that the API knows who is doing the query.
First Step
For opening the session, you have figured it out: you want your API to be an Oauth Client.
So when a user wants to log in, your client will redirect it to http://api.yourserver.com/login/google which will redirect to google, which will redirect again to your API with a token that allow your API to access Google's API (hence, know who your user is).
This token cannot be used to authenticate against your API. Its only goal is to allow your API to act on the user's behalf on google services.
Second Step
Then you need to decide how will your client authenticate against your API. You can choose to use a cookie which almost everyone do (it's the sane default for express sessions).
Or, if your API is consumed by many different clients, and you don't have control over those clients, you can choose to implement an Oauth Server to protect your API.
The clients will then authenticate against your API using a "Bearer Token" (it's an HTTP header).