I am building a Flutter For Web Application that needs to store the credentials in a secure way, to allow the user to automatically login, how can i achive this?
In typical web applications (whether flutter_web or not), it is not wise to actually store the user's password in the browser in a cookie or in html storage. One technique some use is to have a persistent cookie that stores the username and a temporary authentication token of some kind that is encrypted with a private key. The authentication token is temporary but exists on the user record in the database and can be used during the time it is allowed to be valid in place of the user's password. This way the user's credentials aren't persisted in the web browser - only the username and the token in an encrypted, persistent cookie.
From what appears to be in the dev preview of Flutter web is that it produces web applications, and I am assuming that standard web development techniques for user security for any and all web applications should be used.
You can use this package
Seems to me it supports both web and android
https://pub.dev/packages/password_credential
Related
I am implementing a login flow which uses the Google Client ID and Google Client Secret. I am considering the security implications of the Google Client Secret and who should be able to have access to it.
Currently the Client secret is stored in an environment variable, but I would like to know what someone with access to this secret could do with it to determine which developers should have access to this environment variable and if I should setup a different OAuth2 application in development vs production.
Client id and client secret are similar to a login and password. They give your application the ability to request consent of a user to access their data. If you are storing refresh tokens it would also give the user access to create access tokens from your refresh tokens.
Googles TOS states
Asking developers to make reasonable efforts to keep their private keys private and not embed them in open source projects.
You should not be sharing this with anyone. It should only be used by you and your developers.
Yes Ideally you should have a test and production client ids. Test client id can be used by your developers the only one who should be using your production verified project client ids is your production environment. I would store them in some for for secrete store personally.
It depends on which type of OAuth application you specified.
When creating an OAuth client ID in Google Cloud (and with that, a client secret), you are asked to specify the type of application you are creating:
If you choose Web App, your client secret should really be secret, as its treated as such by Google and is used to authenticate your own server. You should therefore hide it and especially not include it in open sourced code.
However, there is also the option of creating a Desktop app, which means you want to use OAuth without having your own server. For this case the documentation by Google says:
The process results in a client ID and, in some cases, a client
secret, which you embed in the source code of your application. (In
this context, the client secret is obviously not treated as a secret.)
So in this case it's fine (even required) to include the client secret in your app for your users.
I have a web server based on node.js which provides REST API. Currently it accepts username and password for authentication. There is a .NET client which offers a login form which gathers the data and sends it to the service.
The new requirement is to offer Active Directory authentication, so that users don't have to input usernames and passwords when logging in to the web server, but can be automatically logged in with the credentials they provided when logging to the machine which is a part of Active Directory and has the client installed. The web service machine is also a part of Active Directory.
This seems like a common problem, and in theory does not seem hard:
The user logs in into machine with client installed
The user starts the client, the client acquires security token from the system
The client sends this token to the web service somehow (in the header, body, does not matter, service will know where to read it from)
The service acquires the token and using the data inside it, gets Active Directory username, thus ending authentication phase
It is quite similar to how JWT works which we use now with the difference that security token is generated not by the service, but by Active Directory.
With theory in place I still can't figure out the minimum project which works on these principles. How exactly does .NET client acquires the token? How node.js service is going to validate it and extract username from it? There are bits and pieces across the net, but nothing actually working in this configuration. There are a lot of third party libraries with sspi, kerberos, passport and ldap in names which only make matters worse, I would like to start with a basic sample, which directly uses system APIs, to understand the principle.
What you are trying to achieve is not an AAD feature.
AAD provides a JWT (OAuth 2.0) with expiration time to your API using your clientID and clientSecret that comes from your client.
Your API serves this token to your client (I suppose a SPA or web application).
Your web application need to store this token until it expires in the browser Session Storage and check for it everytime needs to send a new request to your API.
You can use the refresh_token in your JWT to obtain a new valid token from your API if the one passed from the client is expired:
https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow#refreshing-the-access-tokens
What is the best practice for securely storing authentication credentials in a web extension? e.g. The user enters their username and password, and the extension saves these credentials in order to authenticate to an API in the future.
Currently, I have been using the sync storage, but was wondering if this has the same level of protection as saved passwords in the browser (for example, getting encrypted with a master password)?
Or, is there a method to store/retrieve the login details in the browser's password storage (but, obviously not being able to retrieve any other passwords)?
Do any of the answers above change if storing an API token, rather than full login credentials?
How would I authenticate with Firebase in a chrome extension? I need to specify the allowed domain list in the Forge. Chrome domain for the extension is just a big hash-like string.
I did read this: authClient.login problems
But the hashed based domain of a chrome extension is not being accepted in the Firebase forge. Is there another way to go about it? Currently am just reading the cookie firebaseSessionKey to just assume that I am logged in. But surely that can't be as secure as letting Firebase validate this session key.
As Rob points out, authentication cannot work in an environment that does not enforce origin restrictions. The fundamental problem here is that any authentication provider (Facebook, Twitter, Persona, or your own service) cannot issue an identity to a browser - i.e. it is meaningless to use Facebook to login to your browser (or extension).
The F1 add-on for Firefox ran into a similar problem (http://f1.mozillamessaging.com/) - where you would authorize F1 to post on twitter/facebook on your behalf. The extension had a website to along with it, from where you would serve the login page and proceed as you would normally in a web page. You'll need some code to communicate between the web page and your extension, chrome provides the tools necessary.
I would recommend the same approach - create a web page on a real domain (Github pages is awesome for this) to go along with your extension. This means your extension can't work offline, but neither can your login or writing to Firebase!
This will work using Google Plus Login Flow which I believe is the only one that allows cross authentication so the scopes are Google Plus Login.
"www[dot]googleapis[dot]com/auth/plus.login"
So what is happening here is you will get the access_token from the extension which you will be sending to firebase with the request using authwihtoauthtoken specifying google as a provider along with the access_token acquired from chrome.identity.getAuthToken()!
https://www.firebase.com/docs/web/api/firebase/authwithoauthtoken.html
Now the fact is that this access token could be issued by any other app, so we need to make sure that it is valid and has been issued for our app, basically we need to know there isn't man in the middle trying to access our database.
This verification is being made by the firebase.
They will check if this token belongs to the same application as the token has been issued to.
So you will need to create another set of credentials under the same application in the google developers console as for your extension. We will be basically doing the same thing as if we were to do it for our webpage but we will be inserting this new set of credentials to firebase's google oAuth in their security section.
They will do this check for us there. They will verify with google if the token is issued to the same app.
That's it.
Background Information.
https://developers.google.com/identity/protocols/OAuth2UserAgent#validatetoken
Use case
Sending ID tokens with requests that need to be authenticated. For example, if you need to pass data to your server and you want to ensure that particular data came from a specific user.
When to verify the access
All tokens need to be verified on your server unless you know that they came directly from Google. Any token that you receive from your client apps must be verified.
Google has a tutorial how to do this for python found at:
"github[dot]com/googleplus/gplus-verifytoken-python"
So basically what is happening here is; instead you doing to verification from on your server, firebase does this verification for you when you enter the CLIENT_ID and APP_SECRET into the firebase and enable the Google Authentication.
The way to do this correctly is a combination or same style of verifying to whom the client_secret was issued. Chrome will give you a access_token and then this access_token will be checked on the firebase's backend.
I'm working on a web application which involves connecting to Gmail on behalf of a user to check for new messages. Is there a way to securely store the user's credentials so that they can still be recovered for the login, or is there some way to obtain a token for Gmail to use in connections?
EDIT: The application is meant to be used mostly with mobile users, so they won't be logging into the site frequently. Thus, storing information in a cookie isn't viable.
If you logged into GMail's web interface it gives you a token in the form of a cookie. If yYou could use that token and the web interface then you could access their email without storing their credentials. Of course that isn't IMAP access, and it expires (as a good token should).
Alternatively you could encrypt their credentials with a value you store as a cookie on their computer. Then when they access your site you can check their mail without ever storing the encrypted credentials with the key to decrypt it.
Neither is an ideal solution, but hopefully they get you moving in the right direction.