I am devoloping online store android standalone app(not in webview). I have PHP engine on the server and implemented REST API. But the problem is security between android app and server.
The secure requests shoud be purchase item, view purchased history, cancel order.
My app will let user to enter login and password to login into the app checking data correctness from the server and than user will have an ability to send secure requests.
So the question is how to secure connection ? And how to implement this on the server and client side.
Please give advices how to implement this, and important, what is the best practise to do this to build robust application.
I would be grateful for any help.
You can use OAuth to secure your response - request cycle.
What exactly is OAuth (Open Authorization)?
Generally with RESTful applications, you should leverage the header Authorization. There are several levels of security you can implement:
Basic authentication. It simply corresponds to set a based64-encoded string containing identifier and password
Token-based authentication. It involves a token resource that provides tokens with expiration and that are used instead of actual identifier / password for authentication.
This link provides more details about the way to use these mechanisms: https://templth.wordpress.com/2015/01/05/implementing-authentication-with-tokens-for-restful-applications/.
Hope it helps you,
Thierry
Related
I have an API in Laravel with mostly GET endpoints and an android application.
The application is meant to be open without the need to authenticate, i.e like booking.com where you can browse hotels without the need to login or register.
Anyone can hit my endpoints and get raw JSON data or even make an app that utilize my endpoints in their own app.
How can I secure my endpoint? For example with a token based or any other signature to trust my client app only.
actually I copy pasted this question from stack exchange, but this is exact my question
The Difference Between WHO and WHAT is Accessing the API Server
The application is meant to be open without the need to authenticate, i.e like booking.com where you can browse hotels without the need to login or register.
Bear in mind that even when user authentication is used the API is still vulnerable to be used from other scripts, apps, botnets, etc., provided that they have a user authentication token, and how this can be done this is out of scope for this answer. User authentication only serves to identify who is in a request, not what is making it, therefore, even if your mobile app had user authentication, the API backend would not be locked down to the genuine and untampered versions of your mobile app.
The difference between who and what is accessing an API backend is a usual misconception among developers of any seniority, therefore don't feel "guilty" if you don't get it yet ;)
I wrote a series of articles around API and Mobile security, and in the article Why Does Your Mobile App Need An Api Key? you can read in detail the difference between who and what is accessing your API server, but I will extract here the main takes from it:
The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
Think about the who as the user your API server will be able to Authenticate and Authorize access to the data, and think about the what as the software making that request in behalf of the user.
So, once you don't have user authentication in your mobile app you cannot authenticate and authorize who is in the request, therefore you can only authorize what is doing the request to your API backend.
Lockdown the API to the Android App
How can I secure my endpoint? For example with a token based or any other signature to trust my client app only.
This is a very hard task to achieve, but not an impossible one, and I recommend you to read this answer I gave to the question How to secure an API REST for mobile app?, especially the sections Securing the API Server and A Possible Better Solution, that will let you know about some basic and advanced techniques or link to resources to learn about them, like for example:
Certificate Pinning
HMAC
reCAPTCHA V3
WAF's
UBA
Mobile app hardening and shielding
Mobile App Attestation
Do You Want To Go The Extra Mile?
In any response to a security question I always like to reference the excellent work from the OWASP foundation.
For APIS
OWASP API Security Top 10
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.
For Mobile Apps
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
You could use the OAuth 2.0 client credentials grant, which is suitable for machine-to-machine authentication.
This would mean that your Android app (or any other first-party app) can use a client ID and secret to generate an access token to authenticate against your API, and your API can be locked down to only return responses to requests that contain a valid Bearer token (i.e. no longer public).
I have a scenario, we have an PHP based website through which the users login using credentials stored in a database. Now we have another SPA website with .NET CORE as API layer.We don't have an option of having a central authentication server like Azure. If I want to let the users of SPA to access the website since they have already been authenticated in PHP, What should I do? Can PHP generate a JWT to pass it to API? How does that JWT then gets to SPA and how do I validate it? Please be kind as I am a newbie to website programming.
Json Web Tokens are a very specific format for a Bearer token. There are protocols like OpenID Connect that provide more structure around the login and trust process but at their heart, JWTs are just BASE64 encoded json with a verification hash.
You can roll your own SSO with JWT but as with everything in security, rolling your own comes with significant risks of making a bone head mistake and compromising your security. So research research and research some more if you take this route.
I did a very similar thing but stayed purely in the .net world. I used a .net library to build the JWT (https://learn.microsoft.com/en-us/previous-versions/visualstudio/dn464181(v%3Dvs.114)) and ASP.NET Core Identity to handle verification of the JWT (https://www.nuget.org/packages/Microsoft.AspNetCore.Authentication.JwtBearer) so I didn't write the code to actually generate the JWT. There is also only SSL connections made between the servers so some of the risk of the token getting sniffed is mitigated.
There are libraries for PHP to generate JWT or you could stand up your own JWT token provider in any language.
There also may be the possiblility of finding an OpenId Connect provider that could hook into your existing database. Identity Server 4 is one for .net but there may be one to be found in the PHP world. This introduces some overhead but does solve the problem of not having the ability to have a third party OpenId Connect provider.
Its not too terrible but security is one place where you wnat to be absolutely sure you get things right.
Authenticating from another server is SSO. There are lots of ways you could do this, but SSO protocols like OpenID Connect and SAML are specifically designed for what you're trying to do.
However, those protocols are anything but simple. You should try to see if you can find existing libraries to have your PHP application act as an Identity Provider (IdP), and your SPA to act as a Service Provider (SP) using the same protocol.
An idea that's a stretch - you didn't explain WHY you can't use a central authentication server. You might consider something like Keycloak (there are other options - that's the one I've used), which you can self-host, and can serve as either an IdP or an SP using OpenID-Connect or SAML 2.0.
You definitely shouldn't build this from scratch on your own (unless this is a hobby project). Authentication is full of security pitfalls that can trip up even the most experienced programmers.
Im trying to use ADFS for SSO on a project. The project is on PHP and Im trying to use OAuth for this.
So what are the steps for setting up ADFS to work with OAuth2? I have no idea about ADFS and cant get any direct guide on OAuth2 settings there.
Thanks a lot.
I see that the question is quite old. But in case if other people will
get here, I have some answer which should be good for March 2019.
Let me start with a general overview.
SSO
SSO could be done with personal Google, Facebook, GitHub, Twitter, Microsoft accounts. After logging in to your account, you can log in to other systems (e.g. WordPress or any other) without password (if other systems integrated with that Identity Provider) and you give the consent (see picture below).
There are services whose main focus is to provide Identity Provider / SSO capabilities (e.g. Okta, Auth0, Google Cloud Identity, Azure Active Directory, AWS IAM).
In the corporate network, the user could be silently signed in based on the AD account without entering credentials via ADFS.
Actually, ADFS supports different authentication protocols like SAML, WS-Fed, and OAuth. But nowadays usually services implement OpenID Connect which works on top of the OAuth 2.0 protocol.
OpenID Connect flows
There is a number of authentication flows that OpenID Connect defines.
Most preferable ones are:
Authorization Code Flow with PKCE (single-page applications, native applications)
If you are using oidc-client-js, you should use response_type=code to use PKCE.
Public native app clients MUST implement the Proof Key for Code Exchange (PKCE RFC7636])
https://www.rfc-editor.org/rfc/rfc8252#section-6
Note: although PKCE so far was recommended as a mechanism to protect native apps, this advice applies to all kinds of OAuth clients, including web applications.
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-12#section-3.1.1
Implicit flow considered as Not recommended:
Clients SHOULD NOT use the implicit grant and any other response type causing the authorization server to issue an access token in the authorization response
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-09
Client credentials flow. For service-to-service communication.
How to configure ADFS?
You can find quite detailed documentation with illustrations for "Native app scenario" at Microsoft Docs: Native client with ADFS.
If you are not using ADFS, you can play with the PKCE flow setup in the playground.
JavaScript frontend
Never store client secrets in public applications like JS frontend or mobile apps. It's not applicable to PKCE flow but just in case.
If you have a modern SPA application (e.g. Angular or React), it means that frontend should have only client_id to enable end-user to obtain the JWT access_token in a browser via ADFS. You don't need any client_secret.
oidc-client-js could help you with that. Make sure that code_verifier is being sent along with a token request (it means that you are using more secured PKCE flow).
PHP backend
And on PHP side you'll need to validate the access token. You can implement the workflow on your own according to that article. But it's better to use OpenID certified library which you can find on this page (not only for PHP):
https://openid.net/developers/certified/
So, for PHP there is only one: phpOIDC.
Authentication
OAuth 2.0 can help you only with authentication (to identify the user's identity).
Most probably you would like to have different permissions for different users. And OpenID Connect implementation in ADFS provides you the ability to map AD groups to token claims. Therefore, you can decode JWT access token on the backend and implement claims-based authorization.
To use JWT claims be sure to properly validate the authenticity of the token and issuer:
Validate JWT signature using public key
Check issuer for the proper issuer (Identity Provider)
Check aud (audience) for the proper client ID
Check exp (expiration timestamp)
Check claims
i am writing an iphone app that would need to communicate with our servers. on the server side, im am writing an api in php that the app would talk to. What is the best way to authenticate the apps and basically restrict access to the apps and shut everyone else out?
I need a way of recognizing that an incoming request to the api is a legitimate request from our api.
What other security concerns should i keep in mind and calculate for?
any design suggestions?
i am currently looking into what oauth can do for me here!
I think you don't need oauth because it will only help you when you need authentication involving three parties. Example: your application authenticating a Fecebook user (three parties here: you, Facebook user and Facebook).
I would make sure you use this:
HTTPS (never send password or sensitive data over plain HTTP)
A login.php script that will authenticate your user, and upon valid authentication will generate an access_token for your mobile user.
Each restricted service you provide with PHP will ask for a valid access_token as a parameter to execute.
Make sure your access_token expires after certain time or conditions you might impose.
Look at the big companies? Google uses an API key for all their public APIs so they can track behavior and block if they expect abuse.
Since your API is probably not public you might need more security but then you'd probably need to encrypt all communication :<
I'm developing a social networking website. This service will be available across various mediums, for example: the web, iPhone, Facebook application etc.
My idea for this application was to have all of these properties interact with one central point for fetching and saving data: an API. My various applications would then interact with this API, sending a GET request to fetch some data; a POST request to submit some data; DELETE requests and so on.
This API will be web-accessible, so I need a way to authenticate only white-listed applications. This API will never be available for third parties to interact with or build third-party applications with; it's to facilitate my applications only so I can cut out re-coding solutions across various platforms and focus only on the logic (controllers, essentially).
Therefore, would OAuth be suitable to be used as the authentication method for the above scenario?
My knowledge of OAuth isn't great, but if it is deemed a viable solution then I'll obviously read up on it before implementing. But as far as I know it works on tokens. A consumer (for example, my website) would request a token from the application (the API in this instance) and then the application would return a token to use in subsequent requests. Or something.
When a request comes in to my application, am I then able to accept/deny requests based on the requesting application? I.e. can I deny access to applications that aren't my own? How do I differentiate between applications? Do I retain a whitelist of IP address or URLs, and compare upon incoming requests?
Any help on the above would be most appreciated.
OAuth is not designed to authenticate some applications the way you want to.
Juste create your own private way to authenticate, because you're the only one to know about your API. Dont forget to pipe the authentication in SSL and everything will be ok !
I don't think OAuth is the best solution for your problem. OAuth is great when you plan to give your API to the 3rd parties as it allows to authenticate user without giving users's credentials to the 3rd party. If you have all control over the API there is no need for this.
It's still a good idea to read about it thou. :)