outmoded / oz Goto Github PK
View Code? Open in Web Editor NEWWeb Authorization Protocol
License: Other
Web Authorization Protocol
License: Other
Who is supposed to create and store the encryption password? Is it generated by the server (service provider) or the app (client)? Or is it the user's (resource owner's) password?
Curious if there's support for delegated identity authentication (e.g. OpenID Connect + OAuth2) or it's currently only purely an access authorization scheme.
So recently I have been trying to solve a similar problem to your attempt with Oz, ie:
Making a secure but flexible authorization protocol between applications and some kind of grant / scope server.
So i came up with lummox. It differs from Oz in the following ways:
scope
claim (the user's scope). This scope claim is used to authorize the user for other systems. See full authentication/authorization workflow.While I like the simplicity of just dealing with JSON web tokens, a well known standard, i am concerned about the lack of layers of security in my solution.
So I could implement Oz as lummox authorization protocol, keeping the user management and authentication components.
Would love to know whether people think this would be a good idea? Do you see potnential security concerns with this kind of solution?
The code is 100% unit tested so should make changing it's functionality manageable.
Looking over the sideway client, I think I've got a reasonably working implementation of Oz using the available endpoints (/app, /reissue, /rsvp).
The one thing that I'm unclear of is how an app obtains a ticket that has been authorized by the user.
Here's my best guess:
Questions:
On 1, is the app ticket intended to be used as a temporary "request token" (ala OAuth 1.0), or should something else be used? How do 2 and 4 work? Is it intended to be redirect based, and if so, what are the requirements of the client in order to indicate the redirect URIs?
Excellent work on this!
@hueniverse I'm aware this may be somewhat outside the scope of Oz directly but posting here because I've had these issues with OAuth 2.0 at the company I work for and would like to have at least a little discussion will others that are implementing services with the expectation of both outside integration and internal use.
Originally I had implemented an OAuth 2.0 server in Node.js with some custom additions to it (RSA pub/priv key verification, encryption, etc) because the server granting tokens was not also serving up the data / resources. So because this is already something a third party can't implement with any existing OAuth 2 client we decided any third parties will have to implemented something custom which opens up the door for us to explore a bit.
With these additions the implementation would have worked for a couple use cases but really became unwieldy. As it included more and more resources and user types (I'll explain further down) it just became very clear it was not going to work in the long term.
Our use case is somewhat complicated but I have to imagine others in the open source world encounter issues like this as well.
Given resources X, Y, Z which all have sub-resources such as X.profile, X.orderHistory, etc we were looking at ways for user type X, Y, and Z all to login (separate services, single authentication system). To clarify without going into too much detail imagine X as customers, Y as sales reps / resellers, and Z as employees.
X should be able to login directly and view their profile and orderHistory. Simple enough: [ 'x:profile', 'x:order_history' ]
Y should be able to login as a sales person and view their profile but also details on customers they brought in (this is where it gets complicated). [ 'y:profile', 'y:x:profile', 'y:x:orderHistory' ]
?
This is the problem that I would have to imagine others have faced. I'd be up for writing some sort of validation library that could be used along with Oz but I wanted to sort of throw this out there to see if it was a problem others have seen.
Unfortunately we (the development team at my office) recently took to looking at Amazon's implementation of authentication statements and policies for describing resources but it seems to be far more than we need.
Feel free to close of course if this is something you would rather not even discuss here but if you have any idea where a good forum for this might be I would greatly appreciate directions on where to take this.
Thanks.
Edit: here is a link to the Amazon statements I referred to: http://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies-basic-structure
The current version of Oz is best suited for server-to-server auth, because it uses redirect flow.
Previously you mentioned:
Right now Oz provides an OAuth 1.0-like workflow, but more workflows (especially for mobile) will be added soon.
Any update on that matter?
Thanks for the great repo, BTW!
The only expiration that matters when reissuing a ticket is the grant expiration.
I've been passively watching this project since you've started it, since there are no docs (that I'm aware of), I would kindly ask a few questions:
From what I understand the workflow described in the README is a 3-legged workflow (when there is a third-party involved). To create a 2-legged workflow, is it safe to skip the grant and rsvp steps of the workflow described in the README? The biggest issue I see with a 2-legged workflow is revoking a ticket (or grant).
SIDE NOTE: For those who do not know about or understand the 2-legged, 3-legged, or n-legged workflows, check out http://hueniverse.com/oauth/guide/terminology/
We are currently using oz as the security solution in our framework as we felt it offers the strongest security solution. We are looking to now implement a technology like Kong - which supports OAuth2. There was talk about integrating Oz into Kong but it appears this did not happen mainly because there was no complete spec for Oz -see link above. We could potentially write a Kong plug-in for Oz - however no one wants an unsupported propriety security technology as part of their architecture.
Is there an intention to complete the Oz spec? Is there any desire to have Oz integrated with frameworks such as Kong? Is there a roadmap for this project?
Looking at lib/ticket.js it appears that the random string generated by Cryptiles.randomString is hex-ed to produce the ticket key.
However, Cryptiles.randomString already produces a base64Url encoded string.
Is this a slip or is there a reason for doing this that I am not getting?
Jan
Also, remove scope override in issue()
.
Hi,
I cannot get delegation to work and I don't understand what I have to do.
I'm currently here:
/reissue
with issueTo to the App B identifier. (The request is authenticated with user ticket.)Now I'm stuck. I've tried several thing. I.e. to send the delegated ticket to App B by HTTP POST. And then from App B use that ticket to authenticate with the server. But the server keeps responding Unauthorized.
What is the correct usage?
I know that @rs22 has proposed a rsvp-based delegation flow. ( #48) But I'm simply wondering how the delegation should work on the current Oz release.
I have a question about delegating access to other applications.
From my understanding, if App A wants to delegate access to App B, it will request a new ticket from the 'reissue'-endpoint, stating that it should be issued to App B. App A will then transfer this ticket to App B.
Now when App B starts making requests using the ticket, its App credentials were never actually verified. In other words: It is up to App A to verify the identity of App B when it transfers the delegated access ticket. If it fails to do so, anyone could make requests in the name of App B.
Wouldn't it make sense to have an rsvp-like workflow instead? App A would only request an 'access delegation'-rsvp instead of the actual ticket, which it then transfers to what it assumes is App B. To get the actual ticket from the rsvp, App B would have to obtain an app token first. Now App B could even prove its identity to App A by responding with some key stored in the original token (e.g. in ext.public).
Hey this seems really cool.
In your documentation regarding Hawk, you said Hawk addresses two legged client to server authentication while Oz is for three legged.
Is it possible to use both at the same time? Will there be any conflicts. I noticed that Oz doesn't have much documentation unlike Hawk, and hawk already has implementations in other languages too.
What are the advantages of Oz to Oauth2?
I've been having issues using the Oz.client.Connection()
utility in the browser. At first I was getting weird errors from Wreck because the stream was closed to soon. Then, after I upgraded to the latest Browserify I stopped getting any callbacks from request()
at all (although the requests properly execute and are responded to according to the developer tools' network panel).
Is using Oz.client.Connection()
intended to work in the browser, or has that use case intentionally been ruled out?
Hawk does not allow the expired
attribute so moved it to the error payload.
Hi Eran,
I came across your project while investigating bearer tokens and am convinced I should be using Oz to secure my microservice, but I have no idea how to integrate it. Is there an example app I could look at for pointers?
First off, this is awesome!
As someone that also detests Oauth2, like seriously, I am really happy that we might have a credible way past Oauth2. Hot stuff.
So i have used Hawk Auth before and while I loved it my biggest stumbling point was not being able to use a decent REST client that handled the auth. Do you know of any REST clients that support this new protocol? Alternatively how did you get around this if not? I know unit tests and integration tests go a long way to remove the need for a lot of manual tests but sometimes it is still necessary.
Secondly, can you point me in the direction of implementation examples? I believe hueniverse/postmile is one, though I haven't dug into the code yet. Any others?
X-Forwarded-Host HTTP headers can contain a comma separated list of header names in the case of multiple forwards. The description of the options object in oz/lib/request.js suggest you can simply pass the header value. The corresponding regex however, does not match multiple comma separated host names.
/*
var options = {
hostHeader: X-Forwarded-Host, // Alternative host header modified by proxies
isHttps: false // Used to determine default port if not present in Host header, defaults to false
};
*/
Expose Iron functionality
If I were to add a /oz/redirect
endpoint on the server (service provider) for redirecting to an application. Does Oz now have the same vulnerability as OAuth 2.0 as described here and here?
For example, an application were to try to redirect to the server using its application ticket credentials by doing GET /oz/redirect?to=https://myapp.com
. The server authenticates the user, and redirects back to the application by doing GET https://myapp.com?rsvp=[insert rsvp here]
. Does it matter if the hacker intercepts the RSVP using the redirection hack but does not have valid a ticket object belonging to the application or the application's Hawk credentials?
You asked for questions in issue form, so here is one: Iron is based in deriving keys formencryption and authentication from a password with PBKDF. By default it uses a low iteration count.
I wonder why allow passwords at all. In a similar system I am using (hex encoded) completely random keys (and a tool to generate them together with a random Id). I derive the actual encryption keys with HKDF since I am sure there is no entropy problem with non-humanly chosen secrets.
An app secret is used to sing requests to server. Once app secret is exposed, a third party can use it to perform requests on behalf of another app.
I've read your post about Twitter revoking exposed secrets and got your idea:
If Twitter uses the client secret in installed application for anything other than gathering statistics, well, they should reconsider. But itβs not like they have other alternative.
As far as I understand you, that's fine that an app secret is exposed (it's really not hard to do for mobile apps, for example) as long as server is built with an assumption that that can happen.
Anything changed since 2010? Does Oz addresses the issue in any way? Or it's still better to go proxy way and keep the secret in there?
Hi,
I have been looking into the code and as I am not an expert, nor have examined the code, I would like to ask for the current state of the implementation. Any docs would also be great, but with an updated README would be enought.
Requires long string passwords.
I want to confirm that I understand the Oz workflow correctly after reading the README and the code. Are the following (more detailed) steps describing the Oz workflow (without delegation) correct?
POST /oz/app
request to Server (Oz.endpoints.app()
)
app
object (Hawk credentials with scope
and delegate
)POST /oz/reissue
request to Server (Oz.endpoints.reissue()
)
POST /oz/rsvp
request to Server (Oz.endpoints.rsvp()
)
POST /oz/reissue
request to the Server.When and how is the grant object supposed to be created. Is it derived from the user's username and password?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. πππ
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google β€οΈ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.