I am quite new to the django-rest-framework and building APIs, and I am thinking of way to secure my APIs.
My question is:
How to allow only your front-end application(AngularJS) to call specific (django-rest-framework's)API endpoints?
For the time being I have set permission to all my Views to be IsAdminUser. Also I have created superuser account(for the front-end app). First step is that my front-end app sends requests to login endpoint which authenticates an app, and if successfull, it sends back user token to allow futher API calls. Then user is able to register and/or login, and as soon as he authenticates using his own details, further requests are executed using his own token.
It is working however it is quite spoof. Can someone with more experience advise me on how to allow my APIs to be called only by my front-end client?
Related
I am thinking of using IdentityServer4 for a new project. I am new to this and have done some reading and seen some of the demo clients in action.
Most of the clients in the samples allow login as a User and issue a token.
Requirement
I have multiple applications and the are for example, MVC/SPA/Mobile etc. I wish to allow each application to be a client and call an API.
I need a setup where applications can call a protected API without a user being logged in. So the API is protected based on scopes.
I know I can use client_credentials flow to get access_token and call my API. Which is fine for apps like the MVC as the secret will never be exposed.
I read that this flow is not recommended for mobile/SPA apps and to use Authorization Code flow, but I can't seem to get a token without it asking to login as a User.
Question
What other flow can I use to get only access_token without logging in the user and keeping my app secure?
Or, should I just use client_credential flow in my mobile apps and SPA's?
I've been developing RESTful API server communicating with cross-platform clients such as Android, iOS, Web browser, and so on.
When a user login successfully by username and password, this server issue an access token(JWT, 5 minutes) and a refresh token(GUID, 20 days).
When we develop Android client app communicating with server, we just can store this tokens in mobile device and I believe it will not be a problem in terms of security( using SharedPreferences).
But when it comes to Web browsers, (React App) I had to tackle where to store these tokens. Finally, I decided HttpOnly Cookie, because I can manage easily CSRF attacks rather than XSS.
Soon, I doubt this is a typical design. For example, web browser users cannot logout whenever they want. So I determinate change the wrapper server(Node.js) between the React app and the RESTful API server.
In my second design, the React App and the wrapper server authenticate session-cookie model, using passport.js for exmaple. And when the wrapper recognize the request is authenticated, then the wrapper issue a short term access token(1 minute JWT) and reorganize the request by inserting the access token just issued in the header sent to the RESTful API server.
Is this reasonable process? Thank you in advance.
You could simplify your solution by removing the JWT access token altogether. The refresh token could be used as a session id. Every time a client issues an API call to the server the session id is sent in an HTTP header, so you can check if the request is legitimate.
Your approach of using a JWT token with a short expiration time is ok, but it brings some complexity to your system. In my opinion this approach is best suited for systems where you have an authentication service and a resource owner service. So the client would request an access token to the authentication service and use that token to communicate with the resource owner service. Then the resource owner can check the validity of the access token by just checking whether the signature matches the authentication service's.
I hope this helps you, let me know if I'm missing something.
I'm building a SPA with AngularJS with communication to a Laravel PHP backend. The Authentication method uses JWT, with the tymon/jwt-auth PHP library, which seems to me like a great library.
When user sends his username/password, the service sends back the JWT, which is stored in localStorage on the client. This works fine. However, I want to use a refresh token to continue issuing fresh JWTs to the client, to keep the user logged in as long as he is using the application. Where are these refresh tokens supposed to be issued? Should they be issued when a user sends his username/password? If so, there doesn't seem to be a way in the tymon/jwt-auth library to send the refresh token to the client. Please help, I'm having a lot of trouble conceptualizing how this is supposed to work.
Whether or not you get issued a refresh token when you authenticate with an OAuth 2.0 authorization server depends on which OAuth grant you're using.
When your client is a SPA (an untrusted client), you're probably using the implicit grant and that grant does not support refresh tokens.
Some companies have implemented libraries that are able to refresh access tokens issued by the authorization server using requests in a hidden IFRAME. I'm not familiar with the library you are using.
See also this question for more info.
I'm trying to figure out how to implement the following authentication flow:
The user accesses a web application (most likely to be written using Ruby on Rails) and authenticates (e.g., username/password).
The client consumes data via AJAX provided by a RESTful API built on Google App Engine (Python, webapp2).
Requirements:
Only users authenticated in the web application (Rails) should be able to access the API hosted on App Engine.
Users can have different roles in the web application (Rails), and the API (App Engine) needs to know what roles are associated to the given user to restrict access to certain data.
The client should be able to call the API (App Engine) directly via AJAX, without routing all requests through the web application (Rails).
I'm looking for suggestions on how to implement such workflow. Should I use OAuth (or OAuth2) for accessing the API? Should the OAuth provider live on App Engine and the web application (Rails) ask the API for a token on behalf of the user? If so, what is the best way to allow only the web application (Rails) to request OAuth tokens? Or should I consider a completely different strategy?
Any suggestions are greatly appreciated. I'm also looking for suggestions of libraries to implement OAuth in the context above.
I suggest you use caution if you are considering implementing an API built on the Google App Engine using OAuth for your security layer. I am currently involved in a project that is struggling to solve exactly this problem. The OAuth layer over the GAE is still new and considered by Google to be "experimental". Google's documentation is minimal at this point. What there is begins here. I wish you the best if you try to proceed, and I will do my best to offer help if you do.
My solution to this same problem was to write my own three-way authentication (like OAuth):
After the user is authenticated on the RoR server, it responds with a temporary token. This token is stored on the RoR server, is good for 60 seconds, and contains the user's roles.
The browser sends this token (using AJAX) to the webapp2 server. It's like logging in on that server using just the token.
The webapp2 server forwards the token on to the RoR server to make sure it is valid.
The RoR server makes sure the token hasn't expired and immediately deletes the token to prevent duplicate requests. If the token is valid, the RoR server responds with the user's roles.
If the response from the RoR server is good, the webapp2 server responds to the browser's AJAX call (in step 2) with a cookie indicating that this user is now logged in. The session should contain the user's roles.
Subsequent requests to the webapp2 server will include the cookie so that server can respond according to the user's roles.
We're writing a Desktop application that relies on Google Appengine to authenticate the user and retrieve and store data associated to it.
The way we'd like to authenticate the user is that on launching the application the browser is launched at the login url for our application. Then the user logins there, and then the application makes restful calls without any OAUTH object, but re-using the browser session. I'm questioned that this won't work, since we cannot so transparently use the browser session. Is that correct?
Any alternatives beside authenticating from within the app using the ClientLoginApi?
I'm aware of:
How do you access an authenticated Google App Engine service from a (non-web) python client?
The only way to do this is if you can capture the authentication cookie used by the browser, and send it yourself. Obviously, there's no browser- or platform- independent way to do this.
A better option would be to use OAuth, with OAuth for installed apps to obtain the original token.