I have Web API server and client in browser. Now i want to realize authentication system. Is it good way to store authentication tokens in cookies on client and make every HTTP request with 'Athorization' header(set this header from cookies)?
Related
I have web application which structure is as-
webapi : django web services [NOT REST] no security implemented
frontend : Angular2. authentication implemented via SAML
Database : Mongodb
Can you please suggest best way to secure webapi, as currently anyone can access web services who has server[api] url
It will be big help if you suggest the authentication and authorization flow because I am totally stuck.
Thanks in advance.
Implement an /authentication on your API which accepts Basic authentication. Make sure you do that over HTTPS. Username and password will be collected by your Angular app and sent back to /authentication. If the user authenticates, return a session token, for example JWT (check pyjwt).
All the following communications between the front and back should contain the token, which is issued only if the user authenticated. The token is inclued in the request headers and specifically in Authororization header using the Bearer schema:
Authorization: Bearer <token>
A JWT contains the username so you can use that on each future request. Furthermore, you are not required to keep record of the issued JWT since each one is self-contained and can have predetermined expiration data.
I have a website where I am using regular HTTP API requests and a websocket authenticated connection for realtime data.
I am using token authentication for API requests, authenticating websocket connection upon connection via header token.
I would however still like to somehow uniquely identify a "session", if a user was using the same token on two machines. Do I save a random string generated upon login along with the authentication token, to uniquely identify a session?
Or did I go about this the wrong way and is token authentication really just not appropriate for my case?
Because token authentication is just so much easier to implement on the frontend, as I am using React.
Hi i am new to Apache cxf rest API security side.I want to rest API which have good security with authorization.I found Apache cxf gives Ouath2 security features(http://cxf.apache.org/docs/jax-rs-oauth2.html).So And i need to use json web token(http://jwt.io/) to send to API for authorization.Simply i need to use secured line for send request to rest API.So far i have simple design.
And my REST api have CRUD Operations to database.I thought send JWT as Access token in request header.And API side verify the user and send data back to user.I have two questions.First one is Is this the best design for this kind of application.And second one is if this is best way how to generate Tokens and is that we need to keep those tokens in server side.
Yes it's a good design
I can explain it with github web api's
Authorize
First u validate urself for using API by sending client id and callback url in request (here u specify access level ie.scope) and u receive a code
Access_token
Then u exchange this code for access token (this time with client secret included in req parameter)
This access token received is used for all future calls made by u on behalf of user
Nd ya u store this token and refresh token at server
https://developer.github.com/v3/oauth/#web-application-flow
Although this is specific to github , similar flow follows for twitter , linked in and slightly different for facebook web api's
We have a web application in Spring MVC and also the web services are implemented using Spring Web Service. They are SOAP based.
I have couple of queries in CSRF front.
If there is a CSRF vulnerability for SOAP based web services? I dont think it should be as SOAP is XML. But still not sure if I am missing out on any thing.
If there is CSRF vulnerability for SOAP based web service, then how can a incoming request be validated? As for CSRF the token is once generated by the server and then the client (usually browser) send that token again to the server. How is this possible with web service calls.
Any inputs on this will be a help. Thanks in advance.
If the SOAP service authenticates requests using user ID and password sent in the SOAP header, then it will not be vulnerable to CSRF attacks. Note however that if that service is used by a Web application, then the Web application itself may still be vulnerable to CSRF attacks.
Only if you are authenticating bys somehting that will be sent by the client / User Agent / Browser automatically - such as a Cookie or NTLM / Kerberos token.
In this case an attacker could host a website that posts soap to your application and confince the user to visit it. The friendly browser would just punt the Cookie in with the request (or automatically authenticate with windows if set in browser/site).
I have server with some resources; until now all these resources were requested through a browser by a human user, and the authentication was made with an username/password method, that generates a cookie with a token (to have the session open for some time).
Right now the system requires that other servers make GET requests to this resource server but they have to authenticate to get them. We have been using a list of authorized IPs but having two authentication methods makes the code more complex.
My questions are:
Is there any standard method or pattern to authenticate human users and servers using the same code?
If there is not, are the methods I'm using now the right ones or is there a better / more standard way to accomplish what I need?
Thanks in advance for any suggestion.
I have used a combination of basic authentication and cookies in my web services before. In basic authentication you pass the user name/password encoded in the HTTP header where it looks something like this.
Authorization: Basic QWxhZGluOnNlc2FtIG9wZW4=
The string after the word "Basic" is the encoded user name and password that is separated by a colon. The REST API can grab this information from the HTTP header and perform authentication and authorization. If authentication fails I return an HTTP Unauthorized error and if they are authenticated but are not authorized I return an HTTP Forbidden error to distinguish between failure to authentication versus authorization. If it is a web client and the person is authenticated then I pass the following in the HTTP header with a request.
Authorization: Cookie
This tells the web service to get the cookie from the HTTP request and use it for authorization instead of doing the authentication process over again.
This will allow clients that are not web browsers to use the same techniques. The client can always use basic authentication for every request, or they can use basic authentication on the initial request and maintain cookies thereafter. This technique also works well for Single Page Applications (SPAs) where you do not have a separate login page.
Note: Encoding the user name and password is not good enough security; you still want to use HTTPS/SSL to secure the communications channel.