I have created a public mobile app that use REST API (created with PHP Slim Framework).
I'd like to restrict public access to those API to only people that are using my app, in order to avoid people to getting the API url and pasting it into their browser to easily access my content, for example.
I have found some methods for authentication, but the problem is that my app is already public so if I set an authentication method on my server, then I have to edit my client app too, but people with old app versions could not access API so the app would be useless.
What is the best options I have in this case, to set restrictions to my API without editing the client app?
Thanks
You need something from your app that can be controllable from your api. Such as modal that shows a message that they need to download the new version to continue use.
The logic will be, when the Client app tries to access your Rest API server, check the version from the client app and reject it, then have a message to download latest app.
If you don't have this, the only way you can do is notify your users about the critical update in your application.
Related
I am having a PHP based application, that uses MySQL as the DB. I am currently trying to build a real-time messaging system for the users in the application. I have found Firebase to be a very good solution for building this. However, I am not sure if the architecture I am planning is compatible with the architecture am planning. Digging through the documentation didn't really get me the answers.
My Doubts are:
I don't want users to again login to use chat, so I want to
authenticated via the server (i.e from php).
I want, the further chat/messaging to happen from client to Firebase directly as I don't want to have unwanted overhead on my server, especially when a direct connection is not only supported but also efficient.
Can I authenticate via php and get some secret key or something and then use that to connect securely via Js?
I found this link which talks about custom authentication system. But am not sure, if this is what I have to use. And if the solution am planning is scalable and ok.
Firebase Auth persists the session on the client via localStorage/indexedDB and is a headless API that doesn't require a hosted server. So you are not required to authenticate the user via your server.
You can definitely build the messaging app entirely on the client with real-time database without routing traffic to your server. Here is an example of a chat app built with Firebase: https://github.com/firebase/friendlychat
If you already have an existing authentication system, you can use custom auth which requires that you mint a custom token after you authenticate a user with your system, you then send that custom token to the client and then signInWithCustomToken. Here is some code to create a custom token with PHP: https://firebase.google.com/docs/auth/admin/create-custom-tokens#create_custom_tokens_using_the_firebase_admin_sdk
If you don't have an existing auth system, you can entirely run the authentication on the client side. Another good library for authentication that is built on top of Firebase is FirebaseUI: https://github.com/firebase/firebaseui-web
I'm working on a project where I'm developing a platform. As a solo-developer I made the decision to use Lumen as a PHP back-end and create an RESTful API.
Web shops should be able to install a plugin so they can access the API without having to code themselves.
I need to keep track of the web shops that use the API. I just need the same way to retrieve access tokens like Twitter and Facebook do when you register an app.
So I was thinking about OAuth2 Server but I have never used it before so I'm not sure if I'm on the right path...
If you want your own OAuth2 system then yes you will need a server running it.
The idea of OAuth2 is to authenticate your clients where a shop equals one client.
OAuth2 is not about individual users but clients. With that idea in mind you can setup an OAuth2 server and its only job would be to authenticate each request, make sure it belongs to a recognized client and then issue a token.
With that token you can then go on and issue more requests to actually interact with the system you are building. This is a very high level view of the entire system, of course.
There can be multiple variations on this, how tokens are issued, what type they
are etc. I prefer JWT ( JSON Web Tokens ) as it's JSON and thus lightweight.
A quick search revealed this: http://bshaffer.github.io/oauth2-server-php-docs/overview/jwt-access-tokens/
I do have my own article on building your own OAuth2 system, however it is based on dot net not PHP. You are welcome to use it though maybe it will help clarify the concept.
Here's the link : https://eidand.com/2015/03/28/authorization-system-with-owin-web-api-json-web-tokens/
I've worked on several websites few years ago and I want to be up-to-date with "the new web" so I'm working on a website using Laravel and Lumen to practice.
I have an architecture like that:
An API using Lumen (with databases: users data, user preferences, …)
A website (without database, this part just ask to the API some data and allow the user to be connected to his account)
Currently everything in my API is public: retrieving users, deleting accounts, searching users, etc.
The problem is that I don't know how to allow situations like that:
Allow my website to execute actions calling the API (call private routes on my API)
I would like to have some routes public on my API (the easiest part, it's done actually)
I would like to allow external users to call my API if they have a valid token (Google analytics, Bugsnag like services)
I'm thinking about services like Google analytics, Bugsnag, …: this services ask the user to put a token/key in Javascript. Is it a problem if someone take the token and use it on his personal website and/or in a mobile application?
I've read about o-auth 2, is it the place to start?
Thanks!
I suggest you to try for:
Allow my website to execute actions calling the API (call private routes on my API)
JWT Authentification (JSON Web Tokens).
How do JSON Web Tokens work?
In authentication, when the user successfully logs in using his credentials, a JSON Web Token will be returned and must be saved locally (typically in local storage, but cookies can be also used), instead of the traditional approach of creating a session in the server and returning a cookie. Read more about jwt
Use this JWT-AUTH for connection jwt mechanism with lumen/laravel.
I would like to allow external users to call my API if they have a
valid token (Google analytics, Bugsnag like services)
For that task I suggest you to use OAuth 2.0 protocol
I'm building a REST API using Symfony2 (FOSRestBundle and FOSOAuthServerBundle) and I'm unsure on which grant type to use for this service.
I will have other developers register as users. I was looking at GitHub, and for each user they have a section called 'applications' in their settings which allows adding an application and it gives back client_id and client_secret. But AFAIK GitHub uses the authorization grant type which means you're sent to GitHub to accept and then redirected back to your application with the auth code (does the auth code live forever or what?). I'm not sure if this is what I'm looking for.
What I want is a way to allow developers to consume my API with me knowing who is accessing (FOSUserBundle integrates pretty well here) and what they are allowed to do.
Also, I'll have my own browser based application, Angular.js probably which is the main website where developers can register. It will make API calls to present data for whichever dev logs in. I could use a Node.js backend (need it for some other stuff) so the actual calls are made from there instead as it seems browser only applications aren't really safe. I was thinking of using client credentials grant type from the Node.js backend.
And last, I'll have my own mobile app interacting with the API. Since it's a trusted service it should use Resource owner credentials grant, right?
I'm not sure I understand what you ask for here. As I understand it your developpers will have an account on which they will have to log in in order to use your API. In this case Client Credentials does not seem appropriate, since it would not identify a developper but a client. A client does not represent a user, it represents "an application that accesses your API" (it, in your case you would have one client for your mobile App and one client for your Angular website). I would use a password grant type, that does not redirect you to an external service.
When I had to implement a OAuth2 authentication for my API, I found this article very helpful, it is based on a Symfony2 example but most of the explanations apply everywhere.
I'm trying to implement Google Drive API. They have quick start example here which is using Google OAuth 2.0. Using for a web application where user will use drive api for creating folder and save files, edit files etc.
Now the problem is OAuth 2.0 is redirecting the page and for authCode and then back to callbackUrl again ie. the usual way. Is there any way so that I can get the authCode without redirecting the url, by using cURL or some library that can do that without redirecting.
I'm using PHP for this app.
We currently offer an alternative flow for installed apps that doesn't redirect back to an app but outputs the exchange code. In order to be sure that user is explicitly giving permissions to your application, we need to intercept the flow for a user action.
If there are no end users involved in your use case, you may like to take a look at the service accounts: https://developers.google.com/accounts/docs/OAuth2ServiceAccount Service accounts also provide impersonation for Google Apps domains.