I am looking into adding Google as an Identity Provider for a Single Signon Solution. The problem is that I would very much like to be informed if the Google user that authenticates has Two Factor Authentication enabled on their account or not.
This is where my googling skills failed me however, as I have found no real mentions of the Two Factor Authentication information being available as part of the authentication Token.
So my question is simply how I can discover if a user who either creates an account via the Google IDP, or simply links their account, has Two Factor Authentication enabled on their Google account?
It seems to be possible to do via the reporting API at a later date, but it would make much better sense for my usecase to somehow get the information in the OIDC token.
Thank you very much for any help you can provide.
Having spent a lot of time on google, i finally managed to find a result, which is another stackoverflow post (No surprise there).
In short, it does not seem to be possible, at least it wasn't in 2017. It was a considered feature but was not implemented. The post is here:
Google OAuth2 API. Check user has two factor authentication (Not GSuite)
Related
I work for an ecommerce site and we are looking to expose much of our core functionality via a set of APIs. We plan on re-writing some of our own public facing applications (e.g. the main shop website and our mobile app) to call these new APIs also. We also want to offer some of these APIs out to third-parties who want to integrate with us.
My first question is - what is a suitable authentication method for these APIs? Everything I read is about OAuth, but am I right in saying that this doesn't fit in this case as we're not looking to use another log in system (e.g. Facebook, Google) but rather restrict access to our own API (so maybe an API key or JWT solution would be better?)
Secondly, our current website has it's own user accounts system. How do you offer /user endpoints (like GET user/1235/paymentmethods) in an API like this? Surely the actual user (website customer) needs to authenticate somehow in order for the given API consumer to access their data.
I've spent the last 2 days reading about this but I'm at a loss as to how to go about this! Any help much appreciated.
I'm building an app that requires authentication and I'm worried users might want to be able to remotely log out. Is there a way to use JSON Web Tokens and be able to blacklist or reject them? I understand that their benefit is statelessness, but it would be nice to have a remote logout.
EDIT: With Express.js using the express-jwt module, there is a method to revoke tokens. Also, there is a module express-jwt-blacklist. I still don't understand how these strategies work and would like to know what is the best practice at this point.
There is a nice article on Auth0 about
Blacklisting JSON Web Token API Keys where they give a good real world example on how to blacklist a JWT API key so it is no longer valid. You should give it a read.
Framing the problem
Providing support for blacklisting JWTs poses the following questions:
How are JWTs individually identified?
Who should be able to revoke JWTs?
How are tokens revoked?
How do we avoid adding overhead?
This blog post aims to answer the previous questions by leveraging our
experience from implementing this feature in our API v2.
The article breaks down each point and then shows some example code on how to achieve it and concludes with:
Most of the aforementioned content applies to blacklisting JWTs in
general, not just JWT API keys.
Hopefully this blog post has provided some useful ideas on how to
tackle this problem.
I've personally applied similar methodologies to revoke multiple sign ins where the tokens were used similarly to session ids and stored in cookies. I modeled it like the GitHub profile section where you the user can see all your other active sessions and revoke them (remote sign out) when needed.
As far as best practice is concerned, I believe that topic would be rather opinion based. I do however see Auth0 as source of good practices in this topis area with a lot of people experienced on the matter.
UPDATE:
Found this express-jwt plugin for token blacklisting on npm
In my current work, I have to develop an intern REST API engine.
I have read the Roy Fielding thesis, documented myself, and I finally got something that works great easy to use, with high performance, corresponding to the Fielding REST spec.
There is only one point that I dont really know how to overcome : the security problem.
Again, I documented myself, and I wanted to use OAuth2.0 in my engine.
The problem is that I dont understand nothing at all how to use this protocol.
I dont understand how the consumer can connect himself and be recognized by the server.
I dont understand if I have to provide API key to my consumer(like Facebook, Twitter and Google make it) or if a token will automatically be generated if I send a login / password to the server
I dont know if I have to create my own OAuth2.0 server that provides keys, or if OAuth2.0 libraries are sufficient to provide security.
In fact, I dont understand nothing at all with OAuth2.0, and I need to learn. The problem is, every documentation that I try to read is like chinese, I didn't find an easy one, step by step that will help me with this.
That's why I post here, can you help me understanding a bit more OAuth2.0 and the secured authentication for API ?
I willingly didn't speak about the technologies, because I want to understand OAuth2.0 before applying it technically.
Thanks for all
The main problem with OAuth (both versions) is that you'll see a lot of talk about the three legged version. That is when you have user, a data-providing service and a consuming service, let's say a service that will create physical copies of your flickr photos. In this case the OAuth flow allows the user to tell flickr that the third party can access their data. This is not the scenario you are after, you are interested in 2-legged OAuth, see here for a description.
Of course you could look at other methods too. I've used HAWK in a number of REST/Hypermedia APIs and found it to be great to use in both nodejs and .NET server stacks.
Thank you for your answer, I studied a bit more OAUth2 en tried to implement it with 3 stragery : basic, clientPassword, bearer.
I created a new thread for an other problem, if you want to take part of it :
OAuth2 server creation with nodejs
I'm new to OAuth and I would really appreciate if someone could give me a hand with my problem. I need to create a simple web application for track expenses, with some basic actions (user must be able to create an account and log in, list expenses, edit them, etc) with a REST API for each one, and the trick is that I need to be able to pass credentials to both the webpage and the API. So, after some research I've found some examples using Digest Authentication and HMAC Authentication but lot of posts also mentioned OAuth as an alternative approach, so my question is, given this scenario, would be proper to use OAuth? I mean, as far as I understand OAuth is suitable when you want to share resources with other application, which I'm not doing for this project; besides that, when you try to access the shared resource it appears a page requesting permission for the foreign application, would that page appear at some point in my application? (maybe after the login?)
Thanks in advance guys
In your current scenario it does not make sense to use OAuth. It's not what OAuth is designed for.
If your application ecosystem is going to have multiple webapps running on a single SSO (like google) then it is very helpful to have OAuth.
Suggestion: Decide based on your business/operation plan and implement accordingly.
Note: If you plan to have 10 apps in the span of the next 5 years but only have one app now it does not make sense to spend time to implement complex protocols like OAuth right now. Scale as you grow.
Jeff Atwood argues that we should stop asking users to register on our websites because we should rather use their "internet driver's license -- that is, [their] existing Twitter, Facebook, Google, or OpenID credentials" for authenticating them.
While I am beginning to think that he may be right, I could not yet decide and I am looking for arguments against letting foreign sites gain control over personal web pages.
Do you see any dangers of authenticating users like this?
if you want a more in depth response based from someone who has dealt with this technology before, you should listen to the recent .NET Rocks with Rob Connery which was precisely about this topic.
http://www.dotnetrocks.com/default.aspx?showNum=626
After listening to it I decided to NOT use OpenID on my site.
Here is the link to Rob's blog post on the subject:
http://blog.wekeroad.com/thoughts/open-id-is-a-party-that-happened
Here are a number of reasons why not, although each comes with caveats:
If you only authenticate with one external service, anyone who doesn't use that service cannot use yours.
If your external authentication service goes down, users won't be able to use yours until theirs comes back up; similarly, slowdowns in their authentication server will also affect you.
Requiring users to authenticate with another service requires them to accept that service's EULA, which may be a turnoff for some; similarly, it ties you morally to whatever decisions your authenticating service makes. In particular it can make you appear to be a satellite, spinoff or affiliate of the auth site, since users have to see their logo every time they try to use your service.
The external auth domain gets a perfect snapshot of your viewership, giving them a lot of insight into what your company is doing. Since their analytical tools and staff are generally top-notch, they may conceivably know more about your user base than you do.
The major way to avoid this problem is to allow people to use the service of their choice, instead of a single service. If you are limited to developing one, for development time constraints, using OpenID is the best bet because many other authentication domains also qualify as OpenIDs, and therefore ameliorates most of the above problems.
I think using IDs from any of these big names are ok as long as you don't provide service that needs an endpoint like email, IM etc.
However, OpenID is just not trust-worthy. If you have any doubts, try this OpenID
http://opennoid.appspot.com/anyid
This is a disposable ID that doesn't require a password to login.