I have an api deployed to Heroku. It is currently open for everyone to see. I only want known android phones to be able to modify and access the api.
I don't want the user to have to login every time they use the app.
Can I add some sort of certificate to the phone to verify that it is credible?
Is OAuth the best approach for this?
Is there a better way to do this so the user doesn't have to login every time?
This is a fairly broad question (and hence there are several approaches). Without knowing the language/framework you are using it's also hard to give specific advice, but:
Your server can issue a cookie or token that the client can store locally for a duration. These tokens should include a timestamp and be authenticated (use a library that does HMAC authentication) to prevent clients from modifying tokens.
Clients should present this token or cookie on each request to your server via a HTTP header or the standard Cookie header.
You will need a login system to support the initial issue of the token/cookie.
Clients could also OAuth against your server (complex) or against an external service (GitHub/Facebook/Google/Twitter), but you will still need a way to track that state on the client (hence a token/cookie).
Cookie support should be included with the standard Android HTTP client, and most server side frameworks have support (or a library for) authenticated cookies.
Related
As there is currently no Auth0 SDK for SvelteKit, I am learning (or at least trying to learn) far more about authentication than I originally intended when setting out to incorporate Auth0 into my SvelteKit app (including server side authentication). The documentation is a little confusing (or maybe it is just massive, or maybe I am just not that bright), so I was hoping to describe my auth flow here for critique (in the hope that this will be helpful to others in the future).
I have reviewed this great post about SPA auth as well as Auth0's educational offerings. Still I am not sure I am connecting the dots properly. Here is my flow. All of this occurs over SSL only.
I create an Auth0 client on the client side using their client SDK (#auth0/auth0-spa-js). That client performs authentication via the Auth0 popup.
Once authenticated, everything works as expected on the client side. But if I want to control access to routes on the server side, I need to get information back to the server. So...
After authenticating, Auth0 creates an ID token (a signed JWT) which is stored in the browser's local storage. I save it as a session cookie (with SameSite=strict; HTTPOnly; Secure; options set) so that it gets passed back to the server with requests for route authorization.
So let me pause right here...I understand that (at least according to some including the Auth0 educational video linked above) the ID token is not supposed to be used for authentication and should never be passed around. That is what an access token is for. However, in this scenario where the exchange is all first party (my client, my server), it is my understanding that it is "ok".
However, it does make me nervous that the Auth0 SDK is not setting the cookie itself. This makes me wonder if I am Doing It Wrong™.
On the server I validate the id_token using a public key, and can then save user details, etc. on the backend if I wish, and allow access to appropriate routes (via hooks.server.js in the case of my SvelteKit app).
When the user logs out, or if the token expires, the cookie is removed.
(As a side note, I have yet to figure out how to refresh the ID token when it expires as the Auth0 client SDK does not seem to ever update the ID token in the browser storage even if it is expired.)
Is that a secure and typical way of going about it?
(For a work in progress working example, see my svelteauth0 repo.)
I'm currently developing an identity 4 server, an API protected by scopes defined on the identity server and the mobile app server which will consume information from the API.
By now I already got a good grasp of how to use the authorization and access tokens and how to perform the correct flows, however I got into a dilemma when I started looking at the user session between the mobile app and server. After receiving the access and identity token, which basically serves as confirmation of user login/authorization, which would be the "proper" way to store it and keep the session alive with the app?
Initially I thought of using using cookies, but was told it doesn't work well with mobile apps (I barely know anything about android/ios), to which I followed by considering the creation of JWT on the server, which seemed wrong considering the existence of the identity server that was already producing tokens. And with this, how would I related the session to the access token to perform the API requests?
TLDR:
After fetching access and id token for the client, what "proper"
methods are there to keep sessions alive between client and mobile app?
How to relate the session to the access token to use when API requests are necessary?
Thanks !
For a modern native mobile app I'd suggest using the authorization_code flow (via the default browser on the device) with PKCE and storing a refresh token in the secure enclave of the device. This can then be protected by built in PIN or biometric features.
With that (carefully protected) refresh token you can maintain a long lived session without the need to do front channel (i.e. web browser) interactions with the OIDC service.
I use ajax to store, update and delete resources associated with authenticated user. Routes for these actions use web middleware so cookies, session etc are available. Project is based on Laravel framework.
Is it necessary to protect those routes from unauthorized access in any additional way? I've read about API tokens that one could use, but I am not sure if it is necessary.
I will be grateful for any insights on ajax security or how ajax requests work in general, as it is a little over my head at this moment.
I would say no additional work is necessary assuming you have appropriate checks in place such as a user can't delete another user's entities, etc...
AJAX requests are really just like the user browsing to different pages except it's javascript making requests on their behalf. Since everything is already behind the web middleware, there should be no need for additional authentication since your users have technically already logged in.
Look for JSON Web Tokens
What is JSON Web Token?
JSON Web Token (JWT) is an open standard (RFC 7519) that defines a
compact and self-contained way for securely transmitting information
between parties as a JSON object. This information can be verified and
trusted because it is digitally signed. JWTs can be signed using a
secret (with the HMAC algorithm) or a public/private key pair using
RSA.
and this article:
Authenticate users in Node using JWT and Laravel
We currently support mobile and desktop apps. Our product is somewhat unique. We have our own secure authentication method. However, I've been tasked with integrating Okta to validate credentials in a customers ActiveDirectory. They currently are Okta customers.
Ideally what I would like to do is program our windows .NET client to authenticate user credentials and then pass some information (securely) to our server application such that it can validate the session and then make further calls to the API to obtain user attributes.
We don't currently send passwords in the clear to our server. We use a hash and then just compare the incoming hash to the persisted hash. It seems the easy way to solve this problem is to just allow clear text passwords and then have the server authenticate the user and do all the work and just pass back our own token as part of our usual process.
Is there a way to get a SAML token on our client side to validate on the server side and get access to Okta? Would I have to generate a SAML assertion on the client side and pass the response up to the server?
If you have a .NET application, are you able to enable it with WS-Federation? If so, then you can then follow: https://support.okta.com/help/articles/Knowledge_Article/29510977-Configuring-the-Okta-Template-WS-Federation-Application
Reference: http://developer.okta.com/docs/guides/saml_guidance.html#reference
My web application has a main site, which uses Oauth to log in via a 3rd party service (in this case, it's Github). To preserve the logged in state, the Access Token is stored in a session. So far so good.
There is a part of the application that does background processing. Citing the 12-factor App, it sounds like I should split this part into it's own resource (essentially, a separate application), and send requests over for (asynchronous) processing via HTTP (See Backing Resources).
The problem is, that part needs access to the 3rd party service as well. How can I securely give it the access token?
If it's helpful, I'm using Sinatra, and a handful of Ruby Gems (Rest-Client, Octokit, etc).
After a bunch of research, I determined that the best thing to do is just send the Token over in the message body of the Rest request.
I thought this would be insecure, but it's no more insecure than the request from Github that gives you your access token in the first place. Of course, it important to use TLS (https) to prevent the token from being intercepted.
Here's a great list of security recommendations to follow with Oauth2 Bearer tokens:
http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html#anchor6