I've a simple web api configured for local authentication. This works fine.
I've a console application with httpclient implemented to consume the web api.
When the console app runs it sends credentials in header and receives token and normal operations work.
Since I want this app to run in background and want to keep the user intervention minimal, is there anyway I can do away with username/password without compromising on security aspects.?
Passing on username and password through headers is not a security threat, what you can do to make them safe is encrypt them before sending and then decrypt on API side also make your Web API over HTTPS to make it more secure.
Related
I'm using an external service called auth0 in order to get an access token and let my users use my api. Auth0 is using Oauth2 protocol.
In short The user adds a username and a password, I'm doing a call to auth0 by using a client_id (apps have an id) and client_secret and I get an jwt access token in return. Then from there I carry this access token to have access to my own api since I can check its validity.
I have been looking around about how secure it is to store client_id and client_secret on the client side (e.g. web (javascript)/mobile (native or hybrid with ionic)) and everybody was saying that it's not secure since everybody can reverse engineer the code and get the client_id and client_secret. Ok...I can take it...what Can I do with them if I don't have credentials in order to get the access token?
Given that I don't want to store the client_id and the client_secret, one solutions I have thought is to make a direct call to my api (Java) with the credentials and then my api make a call to auth0 and return the corresponding access token. In this way the client_id and client_secret is stored in the backend and somebody cannot get them easily. Is that safe?
However I have some endpoints, e.g. creating use account, sending sms for phone validation etc, that cannot have credentials. How do I protect the api in such case? If I can't store my own access token on the client side how could I get an access token and access my own api without credentials?
Thanks
One possible solution that OAuth spec suggests is that you could have three different servers for your application.
client-side
backend server and an additional authentication server.
The preferred way of doing this would be that the client would send the user credentials to the authentication server. The authentication server would be a back-end server which contains the client secret
The authentication server will authenticate the credentials and return back the token.
The client will then use the token obtained from the authentication server to access the resource API server.
If you wanna know more check out this video
https://www.youtube.com/watch?v=rCkDE2me_qk
In my opinion you are almost certainly using the wrong OAuth flow. I use Auth0 with Ionic as both a web app and a native Cordova app. I don't have the client secret in my client code at all.
If you follow the Auth0 quickstarts (https://auth0.com/docs/quickstarts), you should be choosing (Native/Mobile App) if you are deploying to app stores, and (Single-Page App) if you are deploying the web version of Ionic. From there you can pick Cordova (for native) or Angular (for SPA). These should give you instructions that implement OAuth flows which DO NOT require your client secret. My guess would be you are referencing a "Regular Web App" quickstart, which runs server-side and CAN safely hold the client secret. That's not the world you're coding in if you are using Ionic Hybrid/Native.
I would consider wrapping the call to Auth0 into your own server side implementation as safe. Your API takes user credentials and then calls Auth0 and this way your client_id/secret are secure on your server and the client can be reverse-engineered all the way without compromising your security.
Regarding the other APIs which cannot have credentials you are pretty much out of luck. Their very use case is to be used by an unauthenticated third party, so at least the account creation API cannot really be protected. However you can still use some nicely designed constraints to limit the attack surface. E.g. you can require an email address/phone number to register and you will not allow the same address/phone number twice. If you set up your process that you first need to confirm your email address before you can validate your phone number this will make the life of an attacker a lot harder. He would need a real working email address, and some automation to receive your confirmation mails before he could get to call your SMS service. You could also rate-limit the service per IP-address so an attacker cannot cause your SMS cost to skyrocket by issuing a lot of calls for SMS validation in a short period of time.
My project is serverless, the user will log in using the hosted sign in UI from cognito, we are only using the implicit grant in our oauth flow, the ui redirects the browser after login being successful but i am concerned about the user's data for being potentially leaked, i know the redirection hash does not contain a refresh token but still there could be a chance that within the token's lifespan it could be expose somehow.
so i was wondering if there is a way to verify with a simple true or false if the user is still logged in with cognito.. we are not making use of any SDK and we don't intend to use them.
if that is not possible then is it possible to change the response scope for /userInfo response to only show few fields?.. to show only email and password
In the end i did not work with implicit grant oath flow for my project, i am now using ELB for handling the cognito's session in the back-end and keep the data only for the server side.
So basically i have a rule in ELB for my project that triggers authentication when a path is accesed, the console for ELB makes it easy to configure and it creates a client session cookie when the authentication is success, this way the Load Balancer can have an easy track of the client that is making the request to a protected route by cognito. Once the authentication is success the Load Balancer sends the authentication data as request headers to the server and from there it is easy to validate and decode the required user data.
I'm having some trouble deciding how to implement authentication for a RESTful API that will be secure for consumption by both a web app and a mobile app.
Firstly, I thought to investigate HTTP Basic Authentication over HTTPS as an option. It would work well for a mobile app, where the username and password could be stored in the OS keychain securely and couldn't be intercepted in transit since the request would be over HTTPS. It's also elegant for the API since it'll be completely stateless. The problem with this is for the web app. There won't be access to such a keychain for storing the username and password, so I would need to use a cookie or localStorage, but then I'm storing the user's private details in a readily accessible place.
After more research, I found a lot of talk about HMAC authentication. The problem I see with this approach is there needs to be a shared secret that only the client and server knows. How can I get this per-user secret to a particular user in the web app, unless I have an api/login endpoint which takes username/password and gives the secret back to store in a cookie? to use in future requests. This is introducing state to the API however.
To throw another spanner into the works, I'd like to be able to restrict the API to certain applications (or, to be able to block certain apps from using the API). I can't see how this would be possible with the web app being completely public.
I don't really want to implement OAuth. It's probably overkill for my needs.
I feel as though I might not be understanding HMAC fully, so I'd welcome an explanation and how I could implement it securely with a web app and a mobile app.
Update
I ended up using HTTP Basic Auth, however instead of providing the actual username and password every request, an endpoint was implemented to exchange the username and password for an access key which is then provided for every authenticated request. Eliminates the problem of storing the username and password in the browser, but of course you could still fish out the token if you had access to the machine and use it. In hindsight, I would probably have looked at OAuth further, but it's pretty complicated for beginners.
You should use OAuth2. Here is how:
1) Mobile App
The mobile app store client credentials as you state yourself. It then uses "Resource Owner Password Credentials Grant" (see https://www.rfc-editor.org/rfc/rfc6749#section-4.3) to send those credentials. In turn it gets a (bearer) token it can use in the following requests.
2) Web site
The website uses "Authorization Code Grant" (see https://www.rfc-editor.org/rfc/rfc6749#section-4.1):
Website sees unauthorized request and redirects browser to HTML-enabled autorization endpoint in the REST api.
User authenticates with REST service
REST site redirects user back to website with access token in URL.
Website calls REST site and swaps access token to authorization token.
Here after the website uses the authorization token for accessing the REST service (on behalf of the end-user) - usually by including the token as a "bearer" token in the HTTP Authorization header.
It is not rocket science but it does take some time to understand completely.
3) Restricting API access for certain applications
In OAuth2 each client is issued a client ID and client secret (here "client" is your mobile app or website). The client must send these credentials when authorizing. Your REST service can use this to validate the calling client
I resolved this for my own API quite easily and securely without the need to expose any client credentials.
I also split the problem into 2 parts. API authentication - is this a valid request from a recognised entity (website or native app). API authorisation, is that entity allowed to use this particular endpoint and HTTP verb.
Authorisation is coded into the API using an access control list and user permissions and settings that are set up within the API code, configuration and database as required. A simple if statement in the API can test for authorisation and return the appropriate response (not authorised or the results of processing the API call).
Authentication is now just about checking to see if the call is genuine. To do this I issue self signed certificates to clients. A call to the API is made from their server whenever they want - typically when they generate their first page (or when they are performing their own app login checks). This call uses the certificates I have previously provided. If on my side I am happy the certificate is valid I can return a nonce and a time limited generated API key. This key is used in all subsequent calls to other API endpoints, in the bearer header for example, and it can be stored quite openly in an HTML form field or javascript variable or a variable within an app.
The nonce will prevent replay attacks and the API key can be stolen if someone wants - they will not be able to continue using after it expires or if the nonce changes before they make the next call.
Each API response will contain the next nonce of if the nonce doesn't match it will return an authentication error. In fact of the nonce doesn't match I kill the API key too. This will then force a genuine API user to reauthenticate using the certificates.
As long as the end user keeps those certificates safe and doesn't expose the method they use to make the initial authentication call (like making it an ajax request that can be replayed) then the API's are nice and secure.
One way of addressing the issue of user authentication to the API is by requesting an authentication token from the API when the user logs in. This token can then be used for subsequent requests. You've already touched on this approach - it's pretty sound.
With respect to restricting certain web apps. You'll want to have each web app identify itself with each request and have this authentication carried out inside your API implementation. Pretty straight forward.
I have a combination Web API and MVC application that is secured using Azure ACS, Windows Identity and passive redirects. This works well. Now I am adding a mobile application using PhoneGap that makes calls to the existing application's API. I having trouble figuring out how to implement authentication on the mobile client. I've got it mostly working, but I can't get the token to client due to the Return URL setting in ACS. The scenario is:
Mobile client sends get request to API
API responds with 401 if user is unauthorized
Client redirects to ACS login page and user authenticates
Token is sent to the Return URL which is the application running on a web server
For example, if I'm running the client app on localhost:63327, the token is sent to localhost:58392 because that's what is set as the return URL in the ACS configuration.
How do I get the token to my mobile client?
I see that people did not really understood your question.
This solution might work.
In a nutshell, is to add a new protocol to get the authentication token from the server to the app client.
PG App calls a web method registering a request to Auth:
POST BeginGethAuthToken
id = pickup Guid
pswd = pickup Password
BeginGetAuthToken can be a web method in your login page.
Server associates the pickup guid with the pickup password
PG Apps start the authentication flow by opening the log-in page using the InAppBroser
mywebapp.com/AppLogin.aspx?id={pickup guid}
The pickup guid is set as a cookie for your webapp domain.
User completes the authentication using the InAppBrowser.
AppLogin.aspx on successful authentication associates the pickup guid with the authentication tokens and ask the user to close the browser to go back to the app
the PG App picks up the authentication token by providing the pickup password.
note that for security the server needs to add expiration policies of pickup guids such that only one app can use a guid at a time and restart the process in case of collisions.
You effectively need to pre-authenticate your client. See http://blog.siliconvalve.com/2013/06/25/protect-your-asp-net-web-api-using-azure-acs-service-identities/
Right now my website has an API which is secured using signed key authentication (accessed using a PHP client). Now, I want to introduce the use of a JavaScript client for use with certain endpoints.
What I've done is require the client to authenticate through the PHP client and receive an access token and a refresh token. Then it is able to pass that token to the javascript client and can access endpoints from there.
Now, what I've having a problem with is refreshing the access token when it expires. Is there a way I can accomplish this without requiring the client to use the PHP client again?
The reason I don't want to use the PHP client is because the app using the api is written entirely in javascript, so using the php client would require the page to be redirected, losing the app's state.
I don't want to use OAuth because I don't want the user to have to grant access to the client. I own both the client and api and there will never be any 3rd party clients created.