Comments (5)
And in many other situations, using one claimed id can lead to multiple
different OP-local identities, so we need to return the claimed id.
Besides, Section 14.2.1 of the specification says:
Although the Claimed Identifier will not be present in the response, it MUST be used as the identifier for the user.
And that's the reason LightOpenID returns the claimed id. It won't break the
specification, especially since it doesn't really make sense to do so.
Original comment by [email protected]
on 18 Sep 2013 at 9:54
- Changed state: Invalid
from lightopenid.
hmm, really... Did not notice that...
But what is rationale behind this?
How to deal with, eg, google? it's claimed id is, as I see
https://www.google.com/accounts/o8/id
Have all of the users share it? how then we would distinguish among them?
Original comment by [email protected]
on 18 Sep 2013 at 10:12
from lightopenid.
Firstly, in case of google, the claimed id is NOT
https://www.google.com/accounts/o8/id . It's the same as op-local id, by
default. https://www.google.com/accounts/o8/id is just a discovery url.
Basically, openid supports two modes, signon -- which you already know, and
server, which google uses. The latter lets an user choose his ID after
discovery, so the discovery url isn't used as a claimed identifier.
Try to log in with google and see the results.
As for the rationale: the claimed identifier is an url that you have control
of. OpenID is a protocol that lets websites determine if you are indeed the
owner of that url. The op-local identifier is just something that providers use
to identify their user.
The case you've mentioned that multiple claimed identifiers point to one
op-local id is perfectly valid - it might simply mean that someone wants to
have multiple identities. On the other hand, if someone wants to change a
provider, he could simply point his claimed identifier to another provider (and
another op-local identifier). In both cases, using the op-local id as a
username would be harmful to the user.
Original comment by [email protected]
on 19 Sep 2013 at 9:19
from lightopenid.
yeah, I did look.
let suppose my website intended to have 1-1 user-to-account relationship. Then
same user claims he is `user1`and receives claimed id like this:
http://openid.mail.ru/mail/user1 and op local id as http://user1.id.mail.ru.
Also, (just for example, not sure about mailru)
he then claims he is `user.1` (by that mail service rules, both these names are
mapped to same user, for example) and in that second case his claimed id
becomes http://openid.mail.ru/mail/user.1 BUT op local id still unchanged:
http://user1.id.mail.ru
So how can I rely on claimed ID?
You can check it with google, it allows such dotted aliases
Best Regards
Original comment by [email protected]
on 19 Sep 2013 at 10:52
from lightopenid.
Your first problem is assumption that you can and should have 1-1
user-to-account relationship. You should instead think about 1-1 user-to-openid
relationship.
When someone logs in with a different claimed id, simply assume that it's a
different user.
Besides, if I recall correctly, nothing stops another provider from using, for
example, google's op-local identifiers (that's why they're "op-local"). That
means that I can create a provider that will return op-local identifiers for
mail.ru. That would be a huge security hole if you used that for user names,
wouldn't it?
Anyway, this is a bug report, and as you've seen, it's not a bug. If you want a
more detailed explanation why the protocol was designed that way, try asking on
StackOverflow, or something. LightOpenID will not go against the protocol
specification even if I disagree with it (which is not the case).
Original comment by [email protected]
on 19 Sep 2013 at 11:20
from lightopenid.
Related Issues (20)
- version 0.5 example works but not version 0.6 HOT 3
- Ax/SReg Params may be unsigned
- LightOpenId constructor fails when trusted root URL is less than 8 chars
- Problem with curl request on a server
- Missing: A License File HOT 2
- add composer support HOT 1
- wrong mimetype check in openid.php ? HOT 3
- Use Steam as provider HOT 1
- #-comments HOT 6
- magic get/set methods HOT 3
- LightOpenID magic properties do not work with Twig template engine due to lack of __isset
- New release HOT 1
- keep waiting for localhost HOT 2
- Validation fails when there are accent in the required variable HOT 2
- Yahoo OpenID not working on newer versions of PHP/cURL [patch proposed]
- The regular expressions in htmlTag parse some valid responses incorrectly
- Support for OpenID Connect? HOT 1
- How to select eid applet language ?
- Unregistered domain error HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from lightopenid.