I have this question. I am quite new in this area.
I have web app.
This consist of services deployed on Docker engine.
The main services/containers are:
Frontend : React on Nginx web server
Backend (API) : Django, DRF on gunicorn on Nginx
For frontend I use Auth0 provider. It works as expected. If user is not authenticated/authorized it is redirected to login page.
Now I want also to "secure" my backend that it only would accept authenticated connections from frontend.
For backend (Django) I also have CORS enabled (django-cors-headers package), but I still can connect from my browser my-site/api/ and get the response.
Does anybody know which strategy should I use.
Should I somehow secure it using JWT tokens. Somehow pass it to backend in my request?
There is various ways of authorizing API calls from your front-end applications to execute actions on your back-end. These will tend to vary in a few aspects:
Complexity
Needing to know who sent the request
Access surfaces
Duration of access
Roles
and so on...
In this case if you have authenticated users on your front-end using AuthO then a JWT could make sense since using this method you can encode specific user data that will allow you to make the decision on your backend as to if that user should have access to that action at that time.
Here is an article explaining a few popular methods of authentication
Related
I have a SAP implemented on the Netlify platform. The processing for the app is implemented in a django api running on a hosted server.
Users are authenticated on the Netlify app, but do not need to be authenticated in django.
I now want authorised users to be able to post data to the api and the django server objects with the message
Forbidden (CSRF cookie not set.): /api/save-archive/{...}/
I am looking at implementing JWT cookies and have considered djangorestframework_simplejwt but that seems to require that the user is authenticated in django
My question is, what software elements do I need to be able to generate and consume a token is this scenario?
Subscription based iOS app I'm building uses Cloud Run service invoked via HTTPS request.
How can I make sure that the request can only be invoked by app owners(from the app)?
I've looked at Google Sign-In authentication, but I don't think it is applicable in my case as only those subscribed to the app should have the access, not just those with Gmail account.
I think without a Google Sign-in involved, your question has nothing to do with Cloud Run and can be generalized as:
How to send requests to to a backend app only from its mobile app?
So I'll answer that.
You'll find out that you need some form of "authentication" to prove that you're on a mobile app as a "user". To achieve that, you need some form of sign-in.
You may try to ship a secret (like a token or private key) in the application and use that to authenticate, but this will be susceptible to:
exfiltration of the private they from the application bundle through reverse engineering
applying a man-in-the-middle attack to the HTTPS request (and therefore the token) by trusting a root CA on the device and using e.g. mitmproxy to decrypt the request as plaintext.
In reality, there's no way to fully secure iOS/Android <=> backend communication that. Even the largest apps like Twitter, Instagram etc have their APIs reverse engineered all the time and invoked from non iOS/Android clients as the requests can be spoofed.
If you want to authenticate your existing users, you should figure out how these people login to your app. This could be simple username:password in Authentication: Basic [...] header, or something more complicated like OAuth2 which is what apps like Facebook, Twitter implement under the covers for their mobile apps.
Then you would validate that Authentication header in your Cloud Run application code yourself.
So again, I don't think this is a problem specific to Cloud Run, or any cloud provider.
If your goal is for your API to only be called when your users are authenticated in your app, I would recommend implementing one of the two solutions described on this page:
Using Google Sign-in or Firebase Authentication
I'm working on an iPhone app that uses xAuth to login to Twitter. The app also communicates with my own web service. Rather than maintain a user model inside the web service, I'd like to just allow anyone who's already authenticated via Twitter to make requests.
The high-level use case is this: the user logs into and interacts with Twitter through the app. They can also interact with my web service through the app. The web service itself never interacts with Twitter. Instead of maintaining a separate authentication system on my side, I'd like the server to say "OK, if Twitter says you're #joshfrench then you can have access."
I'm not sure how I should validate requests on the server side, though. How would I pass some proof of authentication from the mobile client to my web service? Can I send along the existing Twitter token and verify it from the server? Or somehow sign the request with my Twitter app's credentials? Is this even a valid use of OAuth?
If you store your twitter app key and secret on both he iphone app and your server, and then somehow transmit the user's oauth token (also called "access token") key/secret from the iphone app to the server, then you can do the same type of api calls from the server.
consumer = OAuth::Consumer.new(app_key, app_secret, …)
access_token = OAuth::AccessToken.new(consumer, user_key, user_secret)
response = access_token.get('/stuff.xml')
So, is it Okay to transmit that info from the app to the server? If you do it securely, and it's within the user's expectation for how the app behaves, then it's a perfectly fine use of oauth.
It's possible that it's not allowed by Twitter's terms of service -- I could imagine there being something that says you can't transfer a user's access secret across the network, or some such thing. (total wild speculation, I don't think it's particularly likely that that's the case)
everyone.
I have a problem securing my REST web service. It's part of Java EE web application. To secure the pages I used login-config tag and set up "FORM" authentication. Now I don't know how to secure web services, because "FORM" is not appropriate for it and I can't have two login-config tags for app. I considered splitting into 2 apps, but don't think it's a good idea. Any suggestions?
This has info on how to create secured web services using NetBeans: http://netbeans.org/kb/docs/websvc/wsit.html
Many web service providers use an api key to authenticate access to the service. You may want to consider doing something similar for your service.
It is pretty common for the REST API to have a separate subpath - that way you can specify the auth constraint just to the URL's specific to your application and for the URI's corresponding to your REST API implement authentication using jersey OAuth filter or something else.
In case your app is all written in Jersey and you would like to expose exactly the same URI's for REST clients as well as browser (and differentiate just based on the requested media type), you can have a "login" URL (for displaying a login page) and only that you could protect using FORM authentication. Then again you would add Jersey OAuth filter (or other auth filter) which would not kick in unless there is OAuth header in the request, and another filter where you would check if ContainerRequest.getUserPrincipal() is null. If it is null, you could return Response.seeOther(UriBuilder.fromPath("/login").queryParam("redirect", request.getAbsolutePath()).build()).build() - that will redirect to the login (for oauth this would not kick in, since either the oauth request would succeed, or the previous filter would fail and return Unauthorized or Bad Request status codes). In the login resource you can use the redirect query parameter to redirect back to the original page once successfully logged in.
I am making heavy use of async requests by Javascript to the webserver. Since I am building a multitenant application, I want to restrict access to the json services on the user level.
I read a lot about OAuth being recommended for consumer authentification. In my scenario, would the Javascript (client) side be regarded as the consumer and, hence, would you recommend using OAuth for that purpose? If not, what alternatives would you recommend?
OAuth is best at providing a method other than direct sharing of username and password with third party applications or web sites. I would use OAuth or something like it only in the case that you need to provide this type of third-party access to your web application.
If the JS client will be running in a web browser that the user has already logged in to your service, you might just as well use the session cookie that you have already established to authenticate each request.
In fact, such a session cookie will automatically be shared as part of any XHR to your web service.