An external CRM webhook will occasionally call into my CI app to notify me of a data change so I can update the CI app's cache. What's the best way to make sure those calls into my app are from an authorized source?
I looked at options like Tank Auth and Ion Auth but they appear to be overkill for what I am trying to do?
You're probably better off leaving this to the webserver, like adding http auth or ip restrictions. However if you want to do it in CI, you could check the requesting host/domain or IP address as well.
Related
been trying to figure this out forever, and I don't think it's supposed to be that complex...
I have an AzureAD setup with an OAuth2 Connection that I want to point to Cognito so that I can authenticate users in the User Pool, get a token back and call AppSync APIs, etc. Important note here, I cannot use Amplify in the current situation.
I have configured my App Client as follows:
The ngrok URLs are because I'm working on a cloud based app that needs tunneling. I have multiple URLs in there in the hope that I'd get one that works, to no avail.
To configure the OAuth2 Connection in Azure, I'm asked for 3 URLs,
authorize, token and refresh.
Here are the values I put into these fields
When I initiate the auth process with this connection, I get the redirect_mismatch error. I have no idea why. When I open the HostedUI, it shows up just fine, but it points to login instead of authorize. The redirect_uri, however, is localhost:3000/ as seen at the end of the address bar.
Clearly, I'm missing something, but I have no idea what. Should there be additional parameters in the config of my URLs on Azure's side? Anyone ever connected the two in this way? The company insists on this flow, and I just can't wrap my head around it.
Any and all help apreciated, thank you.
NOTE: There is a possibility to configure a custom OAuth2 connection on the side of Azure with more parameters, should this be the way? I do not, however, know what to put in these extra fields.
In the case of a Bot authentication, as it is the case in my situation, in Callback URLs, add the following:
https://token.botframework.com/.auth/web/redirect
This allows to open the authentication window when authenticating your bot.
I have separate backend and frontend. However, they run on the same server (this may change in the future). The backend serves as an api and is powered by Laravel. Frontend by Nuxt (Vue).
I wish only my Nuxt application could access the api. How can I configure Laravel to only return data if the request comes from a Nuxt application?
I thought about adding a special token to requests, but the user will be able to check what request is coming out and capture the token. Can anyone give me ideas how this can be solved?
You must be knowing about CORS. So in your Laravel Server, allow requests from only the frontend server's domain like this:
Access-Control-Allow-Origin: https://www.example.com
Simplest solution would be to add serverMiddleware in the nuxt project and route all the requests to the "real" api through it. Clients will hit the internal nuxt api and they will not be able to see the actual request made to the real api. There you can also add the token you are talking about for extra layer of security.
My webapp has means of abuse, users can access things they're not supposed to, such as 127.0.0.1/users/1 & 127.0.0.1/users/2 & 127.0.0.1/users/3 and so on, within these it reveals the user's registration email, ip, etc (via JSON, so the web server can return customized messages, greetings, and allow users to edit account data within profile settings)
This is what my route looks like:
forum.GET("/users/:user_id", routeFunc(UsersGET))
I'm using Gin-Gonic HTTP framework to create a dummy forum, can someone tell me how to stop users from accessing the /users/ route whilst allowing the actual web server to use freely? and maybe link me to the correct direction. Thanks!
(The server uses it to return things like, Welcome Back, USERNAME).
You need to add authentication and authorization to your server.
Authentication is where a user will prove their identity to you by means of a shared secret (like a password hash) and authorization is where you check if that authenticated user is allowed to take the action they are trying to make.
There are many third party services that might help you with this (e.g. Auth0) where they can handle authentication for you and provide you with libraries for authorization.
Usually people bind authentication into their Gin-Gonic server by means of middleware (e.g. gin-jwt) which is run in front of every http request. Once that middleware authenticates the user, you can add some logic to your handle that states only users can only view themselves.
Hope this helps. Good luck.
I have an api deployed to Heroku. It is currently open for everyone to see. I only want known android phones to be able to modify and access the api.
I don't want the user to have to login every time they use the app.
Can I add some sort of certificate to the phone to verify that it is credible?
Is OAuth the best approach for this?
Is there a better way to do this so the user doesn't have to login every time?
This is a fairly broad question (and hence there are several approaches). Without knowing the language/framework you are using it's also hard to give specific advice, but:
Your server can issue a cookie or token that the client can store locally for a duration. These tokens should include a timestamp and be authenticated (use a library that does HMAC authentication) to prevent clients from modifying tokens.
Clients should present this token or cookie on each request to your server via a HTTP header or the standard Cookie header.
You will need a login system to support the initial issue of the token/cookie.
Clients could also OAuth against your server (complex) or against an external service (GitHub/Facebook/Google/Twitter), but you will still need a way to track that state on the client (hence a token/cookie).
Cookie support should be included with the standard Android HTTP client, and most server side frameworks have support (or a library for) authenticated cookies.
It's common to use HTTPS for authentication, so the authentication details from client cannot be sniffed. However once the user is logged in then subsequent calls to a web app passing some sort of auth id which then the web app will then use to authorise with, should that not also be HTTPS? How is this done in things like Facebook? Seems easier to make all traffic HTTPS.
An answer by Jeff Atwood:
http://www.codinghorror.com/blog/2012/02/should-all-web-traffic-be-encrypted.html
Assuming the server can handle it, I'd go a step further and use SSL for everything, no matter if users are logged in or not.
This has the advantage that an eavesdropper doesn't even know if the user is accessing your site/app as a guest or as an authenticated user. It also saves you from having to decide when to use SSL and when not.