Mobile backend security / Securing an API [closed] - api

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I´m currently designing a mobile application, and I´m having some concerns about securing the backend which runs the services for it to run.
My current planning is, using SSL and a basic workflow like this:
The generated token expires, because it assures that if someone physically access the phone/device, he cant be in control of the user account for too long, but, at the same time, I don't know what duration is appropriated for it, as I don't want to keep asking for credentials every day.
My questions are:
Is this a good aproach? Would you add something else to it?
Whats the ideal duration of tokens when working on mobile apps?

First thing first, you should encrypt session key when you store it on device. For example, use shared preferences with encrypt option. Further info : Android SharedPreference security
Second, you may want to implement "SSL pinning" mechanism. Which means that verify SSL certificates at client side. You must be sure about that received certificate is belongs to your backend or not. So you can protect your backend URLs and parameters with that way. Further info : https://www.infinum.co/the-capsized-eight/articles/securing-mobile-banking-on-android-with-ssl-certificate-pinning or http://www.thoughtcrime.org/blog/authenticity-is-broken-in-ssl-but-your-app-ha/
Third, your design is good. But be sure about your session key generation mechanism is not vulnerability against "Session Prediction" attacks. https://www.owasp.org/index.php/Session_Prediction

Related

IdentityServer4 Architecture [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have integrated my asp.net core app with identityserver4 and succeeded to authenticate and authorize users, my architecture now is as follow:
I have a separate server for identityserver4 with a separate database for all user tables(asp.net core identity tables).
I have an MVC client with a separate database with table called Accounts which hold the userid from identityserver4
I need to do user management stuff I am stuck with two scenarios
1- Create, delete, update accounts from the client MVC app and create an API at the identityserver to reflect that at the table users
2- Allow the client MVC app to access the identity database with identityserver4 and directly do user management
So, what is the best architecture, one shared database for the identityserver4 and the MVC client or or a separate database for identityserver4 and another database for the MVC client?
I would prefer the first option. But it depends on the context and requirements. If you are creating a green-field project that might be larger after some time (which would contain more services), then I recommend you to try microservice architecture.
Microservices often scale much better than monolithic apps but the architecture and overall tech stack might be more complicated. The key point is that they are independent - so they share nothing, database not at all. It comes with other problems, for example synchronizing the databases. It is well described in the free eBook: NET Microservices: Architecture for Containerized .NET Applications (here or here, but you should read also other pages).
If you plan to create just small services that might be part of a non-microservice ecosystem, the 2. choice may be better.

linkedin "this application is not allowed to create application tokens" [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
My main problem is getting the token. I can’t go further than this step.
In the Linkedin API's docs there are two ways described to obtain the token.
Witch is the correct one?
1) https://developer.linkedin.com/docs/v2/oauth2-client-credentials-flow
2) https://developer.linkedin.com/docs/oauth2#configure
I understand that in order to use the new Linkedin API (the partners one) I should use the first one (https://developer.linkedin.com/docs/v2/oauth2-client-credentials-flow)
Here is my petition:
https://www.linkedin.com/oauth/v2/accessToken?grant_type=client_credentials&client_id={MYCLIENTID}&client_secret={MYCLIENTSECRET}
The response:
Error "access_denied"
error_description "This application is not allowed to create application tokens"
And I get stuck here.
With the second one (https://developer.linkedin.com/docs/oauth2#configure) I actually get a token:
https://www.linkedin.com/oauth/v2/authorization?response_type=code&client_id={MYCLIENTID}&redirect_uri={MYURIREDIRECT}&state={STATERETURNED}
This returns the code (and the State) which I use to make the token request:
https://www.linkedin.com/oauth/v2/accessToken?grant_type=authorization_code&client_id={MYCLIENTID}&client_secret={MYCLIENTSECRET}&redirect_uri={MYURIREDIRECT}&code={CODERETURNED}
And I get the token. But this isn’t the correct way to do it, is it?
By default you will need to use the authorization_code flow to obtain an access token. Per the documentation the client_credentials flow is not enabled by default and needs to be specially enabled by LinkedIn.
https://developer.linkedin.com/docs/v2/oauth2-client-credentials-flow

Remember me functionality in IBM Worklight [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
We are using Worklight 6.1 for our app. I want the app to remember the user id (with no limitation on the duration & it should be accurate & reliable).I want to use JSONStore API for this purpose.
In our app, after we gather the user credentials, we are sending them
to an adaptor function, where we are invoking some java classes to
validate the credentials aginst IBM bluepages & also against dbs
I have two questions:
1) When i ensure that user has been authenticated successfully for the first time, I will open a JSON store & keep the userid to the local storage, If I choose to encrypt it , which password I need to supply to make it encrypted ?
2) When the user tries to access the app from the same mobile device, the server should send a login form by pre populating the user id, how do I do this?
Thanks..
Encrypted Offline Cache is deprecated, so you might as well use JSONStore.
In MobileFirst Platform 6.3 ("Worklight"), there is a tutorial that accomplishes exactly your scenario. You should read it and try to implement it in 6.1; depending on JSONStore's featureset in 6.1, you might be able to. You'll need to try.
Here it is: Offline Authentication

Go, basic access authentication [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
Does Google Go support decoding of basic access authentication calls? How do I get the username and password from the http.Request?
Go does not seem to intercept basic authentication when it is typed as an URL in a browser, but it does allow one to get it from some other applications calling it.
For example, using a simple Python code for HTTP JSON RPC:
from jsonrpc import ServiceProxy
access = ServiceProxy("http://user:pass#127.0.0.1:8080/")
print access.getinfo()
And in Go calling:
// r *http.Request
r.Header["Authorization"]
One gets this string:
[Basic dXNlcjpwYXNz]
And
dXNlcjpwYXNz
Base-64 decoded gives
user:pass
So some basic authentication in Go is possible, although it might not be something one can rely on.
There seems to be no way to get the user-provided authentication info, but you can provide the valid username and password for HTTP Basic Authentication by calling SetBasicAuth.

ASP - Biometric Authentication [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed last year.
Improve this question
Cheers,
We started implementing biometrics authentication in our web system and came to a doubt. We're going to use a third-party solution for performing it which is going to be called via a web service.
There are going to be four kinds of authentication:
Regular one: username/password
Challenge
Fingerprint
Cellphone
All users will be authenticated using 1. Optionally, some of them may also require 2, 3 or 4. What would be a good way of verifying which authentication type is required for a specific user?
This is something new for me. Initially, I thought about passing the username from the login page to a web service, which would query the database to check which authentication type is required for this user. Then, depending on the result, the second authentication form would be shown on the screen. Obviously, some extra check would be performed after the user hit the Submit button.
Am I on the right path, or there are better solutions for this?
Thanks,
I guess that would work. Maybe it is an option to do some sort of query in the background (AJAX?) when the username is filled in, so you can dynamically add extra inputs to your login form.
However, this has one potential issue: everybody that knows someone 's username can find out what authentication is required. If that is not wat you want, maybe just ask for a username + password to login to a reduced privelege mode. Then, as you suggested in your question, this reduced privelege mode may require extra credentials to continue to the more secure environment.
You could even make it so the reduced privelege mode will grant access to some of the features, while others require extra authentication (for example: posting a mesage would require basic auth, changing passwords might require all four).