I'm trying to find if a RP(Relay Party) and OP(OpenID Provider) can be on the same domain. We have a use case to implement internal SSO in the future and have being asked to implement authorize on the same domain for each client.
We have a total of 3 domains and the ask is to implement authorize for each. This means each RP will be it's own OP. Apparently this solves an issue with two of the 3 clients, something to do with sessions.
I think this is a bad approach, but I can't find any doc's or case studies to strengthen my argument.
This seems like a misuse of the spec. My reasons for thinking this are:
I can't find any example online where somebody else has called authorize on the same domain
I can't find any reference in the doc's to say you can or can't
Within the FAQ it says:
It lets app and site developers authenticate users without taking on the responsibility of storing and managing passwords in the face of an Internet that is well-populated with people trying to compromise your users’ accounts for their own gain.
Given we are calling authorize on the same system we still have the responsibility of storing and managing passwords.
Questions
Is there any doc's to support or reject this use case of OpenId Connect?Do you know of any examples where it's being done?
Many thanks!
It's not the typical use case for OIDC but I don't think it's a terrible idea. There's nothing in the spec that says you can't use OIDC on the same domain.
From what I can tell, Google has implemented their own OIDC-like flow for all of their products and they all run under the google subdomain.
Related
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)
I am working on a news media website, and I am looking to add feature to allow users to register, login and make comments.
For example (New York Times login/register screen)
May I know what options are available, what are the common approaches publishers would choose ?
So far I have been looking at:
AWS Cognito: Allows to create own user directory, and authenticate.
Disquss SSO: also implemented commenting.
In house development: Code a new microservice to manage user directory and store/serve comments, alternatively using AWS Lambda. I am very keen to go down that path, example, but this might costs a lot to develop + maintain.
User data security is my top consideration, I would prefer to use a separate system to store user data. Either a robust third party service or complete in house development of a new system.
Any suggestions?
Thank you.
These are web-standards for single sign on:
OpenID
OpenID Connect
Companies like Google and Facebook provide authentication using Google-/Facebook-accounts. As far as I know, Google uses OpenID Connect which is based on OAuth. However, I don't know if you don't have to store user data any more at all when using this.
I believe it's worth checking again if authentication and commenting should be combined, especially when using a third-party-solution. It makes it harder to change one of the two.
This could give you some more ideas: https://en.m.wikipedia.org/wiki/List_of_single_sign-on_implementations.
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 seen OAuth2 bandied as the next authentication scheme. The context has been allowing third party clients to authenticate without giving up username/password.
What about the case where I have an API that is not intended for third party access--the only users will be end users via a mobile client that I provide? Would OAuth2 still be appropriate in this case or could I get by using one of the more popular existing schemes, eg HTTP AUTH?
You can do this sort of thing if you want, it's generally referred to as "two legged Oauth". Oauth is a pretty complicated protocol. It needs to be, since it's doing something that's pretty complicated.
Anyhow, we use a two legged Oauth for a few things at work and it greatly over complicates things. The way we're using it, it just ends up a more complicated version of HTTP's Basic Auth, but without any real benefits. There are some valid use cases for two legged oauth, but I don't think replacing Basic Auth should be one of them. http://sites.google.com/site/oauthgoog/2leggedoauth/2opensocialrestapi is a good example of why you might want to use a two legged Oauth, there are a few more scattered around the web.
I'd recommend staying away from it unless you can think of a good, concrete reason to use it. Don't use it just because it's trendy.
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.