I have already created an api using php slim framework. But I have an issue with securing my api. I want to access only api for the authenticated users only.
I have already added user login to my front end angular project. That is fine. But when the someone directly calls the api endpoint its show the result related to that endpoint.
For example. I have the following endpoint.
slimapi/customers/view
This endpoint shows all the data in the customer's table.
When someone types this URL in the browser. it shows all data related to that api endpoint. but I want to show some customers message when someone tries to access my api endpoint without using front end application.
You can Manage JWT Token
when client sends you login request and if login request and credential matched then you give the client a token. Then After every request, you check the token is it valid then you give the access.
just see the documentation of JWT
https://github.com/tuupola/slim-jwt-auth
You could use the OpenID Connect protocol (based on OAuth 2 and JSON Web Tokens​).
But this would maybe an overkill for the most scenarios, because a JWT would only makes sense if you have to scale the "session" over multiple servers and/or load balancers in the back-end infrastructure. Also a simple logout is not possible with JWT based tokens. If you start to manage JWT blacklists on the server-side, the API will not be stateless anymore.
I think a very long API-Token within the HTTP header, e.g. a UUID, would be secure and good enough in the most cases.
The HTTP Authorization request header contains the credentials to authenticate a user agent with a server, usually after the server has responded with a 401 Unauthorized status and the WWW-Authenticate header.
Syntax:
Authorization: <type> <credentials>
Basic Auth
Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
Token based
Authorization: Bearer eyJhbGciOiJIUzI1NiIXVCJ9...TJVA95OrM7E20RMHrHDcEfxjoYZgeFONFh7HgQ
UUID as Token
Authorization: Bearer bb79dfb5-17fd-4ebc-acd5-548e308e5f9a
Also make sure, that all API request are SSL (HTTPS) encrypted.
PS: If you just want secure your API for a web application, a classic Session with Cookies is also good enough and very secure.
Related
I use firebase authentication in my laravel project and I am curious if there is such a way to give users roles/permissions.
Normally I use laravel authorization to get over it but now my user data are on the firebase.
Firebase Authentication (as its name implies) only handles authentication: verifying the user's identity. It intentionally does not provide any form of authorization: determining what the user's access permissions are.
Many of Firebase's other products have their own authorization mechanism that builds on top of Authentication, such as the server-side security rules of the Realtime Database, Cloud Firestore, and Cloud Storage.
You will need to do something similar in your own server-side code to implement authorization for your app. You'll typically follow this recipe:
Pass the ID token of the user from the client to your server-side code.
Decode and verify the ID token to securely determine who the user is.
Look up the authorization of the user, either in a data store of your own, and/or from the custom claims from their token.
Enforce that the user only accesses the data they're authorized for.
This is pretty much the same process that Firebase's own services also follow.
I need to use Quickbooks online API to synchronize data between my system and my client's accounts on quickbooks.
I need to know if is it possible to complete the oauth2 authorization flow and make API calls without human interaction (without the need to interact with Intuit's authentication and authorization windows)?
I read the Intuit's docs on: https://developer.intuit.com/docs/0100_quickbooks_online/0100_essentials/000500_authentication_and_authorization/connect_from_within_your_app
On the first step, I made a GET request to:
https://appcenter.intuit.com/connect/oauth2?client_id=MY_ID&scope=com.intuit.quickbooks.accounting&redirect_uri=https%3A%2F%2FMY_NGROK_URL.ngrok.io%2FOAuth2PHPExample.php&response_type=code&state=RandomState#/Authorize/COMPANY_ID
Then, the Intuit's authentication and authorization windows opens and I need to put my username and password and then, click in the authorize button to get the authorization code.
Is there a way to obtain the authorization code without authenticate and authorize?
I need to automate this task to make API calls in the backend with PHP.
Thanks,
Marcelo.
Is there a way to obtain the authorization code without authenticate and authorize?
No... but read below.
I need to automate this task to make API calls in the backend with PHP.
You are misunderstanding how OAuth (either 1 or 2) works.
The very first time you connect you will be prompted to authenticate/authorize access to the QuickBooks Online data.
You are then given a refresh token (or access token depending on if you're using OAuth2 vs. OAuth1).
You then store that refresh token (or access token for OAuth1) and can use that token going forward to make your requests, unattended, without requiring the user to be involved at all.
Key take-away: You only need the user involved the VERY FIRST TIME you connect, and then never again.
I have a hybrid SPA php web application that makes calls to a remote REST API for all it's needs. I'm starting to implement token authentication between the web server and api and I'm not quite sure how to handle expiration of the token. There may be some flaws in my design as well.
User submits login credentials (username & password) to the web server.
Web server sends call to the API.
API looks up creds., if good, a JWT Auth token is generated and returned to the web server where the Token is stored in a php session variable. The token is never made public.
Each call the web server makes to the api sends a request with an authorization header that includes the token pulled from the session.
My problem is, what's the best way to issue a new token if one has expired during an incoming request. The api checks each request's token to determine if it's valid and if it's expired. If the request API was GET foo/bar for example, expecting a JSON string in return, but the token has expired, what would be the expected behavior?
Hope this makes sense. Please let me know if I'm not clear enough. Have not had much luck researching this particular scenario.
I am currently learning about OAuth2, and I am slightly confused about one part of it. Does the OAuth2 server compare the domain in the JWT with the domain in the request header?
What prevents someone from ripping a bearer token out of a JS app and then using it to make fraudulent API requests? Even if HTTPS is used, the token sent back from OAuth2 still has to be stored before it can be used in subsequent requests, thus making it vulnerable. What am I missing?
Edit: what if I create an oauth2 token from a non-browser client and there is no domain name to match against?
Nothing prevents it from being used. That's why you store it safely or you don't store it at all.
Twitter'll phase out HTTP basic authentication by August 2010. In the link my scenarios are from Desktop Applications. Basically my client should tweet new posts on a website.
This would be incredibly simple with HTTP basic auth, because I can store and use my account's username and password in the app to authenticate.
However, with OAUTH I can get final credentials by two means:
Callback method. You are redirected to Twitter, (login if isn't), click allow access, get redirection back to your callback URL.
PIN mode. You get a link to open, (login if isn't), click allow access, receive PIN code. Use this PIN code to authenticate your app.
Do I understand correctly that PIN codes also expire? How is it possible, given a username and password just to tweet from a client application? How can a server side script log in with the username/password and click allow access? All scenarios I could google up are for a web application to authenticate via twitter where the user is in front of the browser to walk through the redirect.
All scenarios I could google up are for a web application to authenticate via twitter where the user is in front of the browser to walk through the redirect.
The user has to be there to authorise you the first time (just as they'd have to provide you a username and password), but the resulting access token does not expire and can be reused (unless the user deauthorises your application, that is).
Store the access token - it's as good as a username/password. Better, actually - if they change their password, your access remains.
The PIN does expire under OAuth 1.0a. Using the verification code returned requires use of the temporary request token in the initial authorization request.
OAuth 2.0 defines more flows - one of which uses a direct login/password mechanism. It's up to Twitter to determine which flows they decide to implement. You can also embed a user-agent in the app.
Desktop apps suffered from a really bad user-experience with OAuth 1.0 which led to 2.0. It's doable, but painful. You can request XAuth access if you need to from Twitter as well. It's almost the same as basic auth.