I'm familiar with mailto:// links; that's not what this is about.
This is more akin to Sniper Links, which are useful to reduce friction in the process of confirming a new user's email address. We've just sent the user an email, and we want to give them a one-click way to go find it.
Sniper Links, as described at the link above, are great for that, but they're limited, in that:
The user must have a web-based email service.
We must be able to determine the mapping between email hostname and email provider (e.g. "some.guy#gmail.com" should go to the Gmail interface).
Those are mostly solved problems. Most people these days do use web-based email, and many who instead choose to use dedicated apps can use a web-based client. This is not universal, of course.
Mapping between hostname and provider is sometimes trivial (like the #gmail.com example above), sometimes not (#somecompany.com -> Google Apps is less obvious). If it's not directly obvious from the hostname, an MX record lookup will reveal the truth in the case of Google Apps and a most of the other big names in corporate email hosting. Services like ZeroBounce offer APIs to do the lookup and translation for you, for a fee.
But there are users whose email addresses do not have web interfaces, or for whom the URL of the web interface is not easily determined. For these users, I'd like to be able to bring up their preferred email client (assuming the browser -- or the underlying OS -- knows what it is).
I know that a mailto:// link will launch the default email client (whether web or app) and start composing a new outgoing message.
From a web page, is there a way to launch the default email client without starting a new outgoing message? I'm assuming this would take the form of a URI scheme, but it could also be a JavaScript API call or something else entirely.
Bonuses:
Also cause it to navigate to the inbox
Navigate, search, or filter such that we're likely to find our specific message (based on sender, date, subject, mailbox, etc)
Navigate to the precise message we just sent
No, that is not possible. Browsers won't open Apps "without" a reason. This could also be a major security risk, if they would do.
Related
we are trying to build an application which is accessable via onetime passwords without a "user" having the need to register.
We did came accross the term magic-links sent via email, but there is only some old experimental keycloack extention for this.
Is there any way to build some auth flow like the following with keycloack?
User A is a fully registered User creating some document. This document needs some interaction with a Third Party Person (TPP) not registered.
Now User A sends an E-Mail invite to the TPP with a link to the document. When the TPP opens the link our application should ask for the email address and send a magic link or code to this email. Whith that email or magic code the user gets access to the document for the time it takes to complete the approval process. After the work of the TTP is done, the access should expire (or expire automatically after X days not used).
It does sound quite similar to what is possible with SaaS offerings like https://magic.link/ or https://www.arengu.com/ but we are using keycloack and would like to integrate it into it as well.
Does anyone have an idea how to achieve this with keycloak?
I know this is outdated, but perhaps someone else coming along may find this useful. There is a newer implementation of this feature provided here: https://github.com/p2-inc/keycloak-magic-link
We have found it usable and useful for our needs and works well in the latest version of Keycloak (18.x).
I'm considering building a website user authentication system using only one-time-passwords: users would get one in the email each time a normal password is normally used e.g. for signup, sign-in, risky actions and account deletion.
Some problems that I see with it that don't seem critical:
Can't change password to invalidate all existing sessions - can work around by storing sessions server-side and having a way to invalidate them for the user
Anyone can check if a certain email is registered in the system - doesn't seem like a critical problem for a generic website
Anyone can request an OTP for any email - will be dealt with using API limits per remote connection and a limit of 1 unused OTP per hour
I'm not seeing this method mentioned or used in the wild though. Does it have any major drawbacks? Many thanks!
OTP-by-email only is safer than password-only (it's basically like forcing the user to change their password every X hours).
I want to both address some of your non-critical points, and highlight some drawbacks.
Non-critical
Invalidating sessions
You don't have to store all sessions, only the invalidated ones, and only for the max duration of a session.
Checking that a user (email) is registered
That actually is a problem - it tells you that the email owner uses this website, which is a privacy issue, however minor.
But moreover, it's an attack vector. An attacker can scrape your user list, or just go attack that user on other sites, presuming that this email exists and links to a real human. Moreover, they can issue excessive OTP requests on their behalf, which I'll address in a bit.
All that said, there's no reason which this problem would manifest just because of OTP. A user can request OTP, and you can always reply with "If the email address hello#world.com is registered, a one-time password has been sent to it". This only has a slight usability implication.
Anyone can request OTP for any email
If an attacker can flood your site (from different IP addresses) with requests for OTP for hello#world.com, either you block this user (namely, that user has been DoS'ed), or you the site will flood the user's mailbox, which can get that mail server to flag the site as a spammer.
This could also be done in normal sites with password-reset emails, but that's why you typically want your user list to be secret.
Bigger drawbacks
Usability
OTP-only login assumes that the device from which you're logging in is also logged into the mail account linked to this site. Otherwise, the user has to log into the mail account in order to log into your site.
Single-factor authentication
The security community is pushing towards multi-factor authentication, where password is usually the first factor. A good practice would be to at least allow 2FA to users who choose to.
Account lockout
If a user's email account is no longer accessible for whatever reason (e.g. they used their work or university email), they can't log in, or even change their email address to their new one.
Email activity
If the site is heavily used, then it will be sending a lot of emails, to various public email services, continuously, all the time.
This alone may cause the site to be flagged it as a spammer, or even ratelimited.
If it does get ratelimited, some users will not be able to log in.
I want to write a google chrome extension, that should make a request to my website to send and get some data, so, actually I should do an ajax request like it is written here https://developer.chrome.com/extensions/xhr.html
var xhr = new XMLHttpRequest();
xhr.open("GET", "http://api.example.com/data.json", true);
I wanted ask if there is a way to somehow secure the code or prevent others from using my api, because actually the other users can see the source code of the extension when they install it and so use my api without me being aware of it.
EDIT:
If I need to make some sort of authentication, than how can I authenticate the user before making the ajax call ? for authentication I will need to send a request to my server , but for that I should send , e.g. username and password, that should be saved somewhere in the extension's files, which, in fact, can be seen by the users, when they install the extension.
Thanks
Don't trust the browser, take steps to authenticate the user instead. So, in this case, you could require that YOU enter in a password that is used to communicate with your server.
Your Google extension would simple require you to enter in a password before it attempts to use AJAX to communicate with your server.
Be aware that you should build in means of protecting yourself from brute-force attacks. So, do things like lock everything down if there are more than some small number of wrong passwords, etc.
You could also consider using the password to simply decrypt the destination of the XHR, but if you go this route, you should store this very carefully, because this will be brute-forceable offline.
EDIT
Trying to lock down an API so that only a single application can use it is just not practical nor technically possible, so you're only hope of doing this is to authenticate the user using the API, regardless of the accessing software he is using. You could have the user sign an agreement that legally limits them to only your extension, but I suspect this will go largely unenforceable and will consume your time tracking abusers down.
If you don't want unauthorized people even knowing where the API is, you could perform authentication using an out-of-band mechanism: over the telephone, email, SMS, or simply, another API that will grant the user a password or token that requests to your API must be accompanied with.
During this out-of-band process, you could also grant the user, a unique URI (the API access point) that is only valid per authenticated session (https://api.totally-cool-extension.com/api/ijyeDvB5dYvSiWG97OLuTAoNWwbhuZ0/, for example). Any requests to your server on OTHER URIs simply won't work. However, this isn't theoretically much different than using the same API access point, and having a good password. It just changes the number of places in your architecture that will be performing authentication and/or authorization checks.
<aside>My vote would be to reduce the number of authorization/authentication points to as few as possible so that you can spend more time on getting that one place correct rather than having multiple places and possibly multiple logic flaws or other things that could lead to vulnerabilities.</aside>
You could also explore using Public Key Infrastructure and/or one-time passwords schemes or device-based token generators, etc., but in the end, you'll be allowing authenticated and authorized users to use your API. And, thanks to the Internet, this will not remain an undisclosed URI for long.
And, more importantly, it will not prevent someone from using the data on their own. Even with all these measures in place, it would be trivial for an authorized user to collect this data as it is being streamed to your extension. Or, if you employ point-to-point encryption, they could screen-scrap or use some form of JS introspection on your very code or even extract the data from their computer's memory.
I know you were looking for a silver bullet here, but it doesn't exist.
I think you are doing it wrong. You should never trust what's going on on internet users PC's. Never!
Move the line of trust one step inward, make your API public and then design the security where you have perfect control - server side.
I could not get correct aspect of your use case
Few Points:
Your extension code is always traceable( Any one who has installed extension can view the code)
If you are looking for security through complicated or obfuscated coding patterns you end up slow down of understanding process not the whole.
If your target is to ensure users who install your extension should be able to access and inert all other users( Who have gained illegal access or downloaded and edited code) have a session shared key per installation.
Please explain further use case so i can help you better.
Should the HTML5 database be used to store any form of private information?
Say we have the following scenario;
You're browsing a web-mail client, that uses the web database to store mail drafts after you've written some information you close the web browser. What's to stop me from getting access to this information?
If the webpage tries to clean out old information when opened a user-script could easily prevent the website from fully loading and then search through the database. Furthermore the names of databases and tables are easily available through the web-mail client's source.
W3C Draft
The only way an external party could access the user's database is via direct access to the user's computer, or if your web app has a security vulnerability (such as XSS - Cross Site Scripting). Otherwise standard browser security dictates that only scripts running in web pages from a certain domain can access databases that were created/stored on that same domain (same origin-policy), same thing that stops you making cross-domain Ajax requests, or reading other website's cookies, all of which can be overcome via an XSS attack.
To me, storing a draft email seems reasonably sensible, whereas things like credit card details, passwords etc. should be stored exclusively server-side. You'll need to make a call as to what should be stored where, based on what you're going to store.
Should the HTML5 database be used to store any kind of private information?
Depends on how sensitive the information is. I wouldn't want to leave credit card details lying around anywhere.
You're browsing a web-mail client, that uses the web database to store mail drafts after you've written some information you close the web browser. What's to stop me to get access to this information?
Assuming you don't have physical access to the computer (in which case the user needs to take relatively extreme security measures) and you don't run the email service (in which case you need to have access to emails) then standard browser security stops you.
I'm reading about Federated Login for Google Account Users to figure out how I can have a user log in to a web application using their Google Account.
So towards the end of the process, Google returns a Google supplied identifier which is appended as openid.claimed_id. This means the web application uses this identifier to recognize the user and allow access to application features and data. My question is, is this identifier static? Can I use this identifier to repeatedly id the same user?
Yes. Consider the openid.claimed_id value to be the username. Especially with Google, but this is true for any OpenID Provider that truly implements 'directed identity', don't consider this username to be correlatible with other web sites. Any other relying party besides your own web site will get a different claimed_id value for the same Google user, by design.
Also, be sure to treat this claimed_id as case sensitive.
The specific answer to your question is found in Googles OpenID API documentation:
The Google-supplied identifier, which has no connection to the user's actual Google account name or password, is a persistent value; it remains constant even if the user changes their Google user name and/or email address. This identifier is also a "directed identity", that is, Google returns a different value to each relying party. Google uses the request parameter openid.realm to recognize the relying party, so if the third-party application decides to change this value, all user identifiers will change.
In fact, I just ran into an instance where the google claimed_id had changed for my test user. I was coming to the end of implementing OpenID into my app, and for no apparently reason the claimed_id in the response data is had changed.
I've been testing with this account for the past couple weeks, and the claimed_id was the same this entire time, as expected. Then wham, changed! I looked at the response data many times to verify, and the underlying code to retrieve the data had not changed.
I'm not sure how to handle this at the moment, but I think this is going to throw me for a loop. After initial authentication, users register to the site (as you might expect) and setup a screen name. How are we to verify it is the same user if the claimed_id had changed? We certainly can't use email address, per best practices.
EDIT
Now I have pie in my face! I missed one little detail, that turned out to be a major detail. I change my development environment and was hosting on a different v-host. This effectively change the realm, and this will change the claimed_id response according to the docs.
This was a good lesson for me, as I was about to implement OID on a subdomain in which realm was being set automatically in my code. Now I saved myself a headache down the road, because I would not have been able to use the same user database across all other sub-domains without breaking identity.
updating realm
MORE INFO
Just as a side note - even if you are developing your OpenID solution for one of your subdomains, it might be prudent for you to specify realm to your top-level domain.
e.g., openid.realm = http://*.yourdomain.com
It will allow you to expand your sign-in page across all your subdomains and keep user identity across them.
(optional) Authenticated realm. Identifies the domain that the end
user is being asked to trust. (Example: "http://*.myexamplesite.com")
This value must be consistent with the domain defined in
openid.return_to. If this parameter is not defined, Google will use
the URL referenced in openid.return_to.