outmoded / oz Goto Github PK

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:

• It is designed as a highly configurable user management, authentication and authorization service for distributed systems; it deals with user's CRUD and authentication.
• Once authenticated, a user generates a JSON web token with an embedded scope claim (the user's scope). This scope claim is used to authorize the user for other systems. See full authentication/authorization workflow.
• It does not deal with secure storage of this token.
• It does not deal with securing the transport layer.

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.

Requires long string passwords.

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?

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?

Expose Iron functionality

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().

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:

1. App calls /app (with credentials) to get an app ticket (with optional requested scope?)
2. App sends app ticket to Oz authorization server for user approval
3. Oz authorization server conducts dialog with user to grant access
4. Oz authorization server issues rsvp ticket to app
5. Application exchanges rsvp ticket, at /rsvp, for an authorized user ticket.

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!

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).

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?

Kong/kong#511

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?

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/

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?

When and how is the grant object supposed to be created. Is it derived from the user's username and password?

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!

Curious if there's support for delegated identity authentication (e.g. OpenID Connect + OAuth2) or it's currently only purely an access authorization scheme.

@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

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?

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:

• who implemented it by now? (wallmart?)
• the progress was as you expected?
• the overall concept was a good or you have a new idea?
• is there be a beta version + docs planned?
• can we (watchers) write docs and ask for feedback where we don't understand parts of the code?

The only expiration that matters when reissuing a ticket is the grant expiration.

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
};
*/

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 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?

0. (Before the workflow starts) The application is registered with the server and is assigned Hawk credentials, which include an application ID and a randomly-generated key.
   • NOTE: The method in which this is done is not part of the Oz protocol
1. Application: Make POST /oz/app request to Server (Oz.endpoints.app())
   • Send Hawk credentials or an app object (Hawk credentials with scope and delegate)
   • Get application ticket in return
   • NOTE: This step allows the application to manage its own resources on the Server
2. Application: Make POST /oz/reissue request to Server (Oz.endpoints.reissue())
   • Send the scope array (optional) and the application ticket ID (as an Hawk authenticated requested using the application ticket)
   • Get new application ticket in return
   • NOTES
     • Keeps the application ticket fresh
     • May not be necessary, especially if the application just obtained the ticket
3. Application: Direct user to the server (possibly by redirecting)
   • Sends the scope, application ticket ID, and (possibly) callback URL (URL back to app)
   • NOTE: The method in which this is done is not part of the Oz protocol
4. User: Log in to the server
   • NOTE: The method in which this is done is not part of the Oz protocol
5. Server: Display scope (sent by the application in Step 2) and prompt user to approve the scope
   • NOTE: The method in which this is done is not part of the Oz protocol
6. User: Approve scope
   • NOTE: The method in which this is done is not part of the Oz protocol
7. Server: Receive approval from user
   • NOTE: The method in which this is done is not part of the Oz protocol
8. Server: Generate RSVP
   • Get application ID (extracted from the ticket the application used to authenticate)
   • Create grant object
   • Create RSVP using application ID and grant ID (an iron-sealed string)
9. User: Receive RSVP from server
   • NOTE: The method in which this is done is not part of the Oz protocol
10. User: Give RSVP to application
    • NOTE: The method in which this is done is not part of the Oz protocol
    • If the application received the RSVP from the server on behalf of the user (by redirecting back to the application), then Step 9 is not necessary.
11. Application: Make POST /oz/rsvp request to Server (Oz.endpoints.rsvp())
    • Send RSVP
    • Get user ticket in return
12. Application: Can now use the user ticket to access user resources
13. Application: If the user ticket expires while the user grant has not expired, renew the ticket by making a POST /oz/reissue request to the Server.

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.

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.

Hawk does not allow the expired attribute so moved it to the error payload.

Hi,

I cannot get delegation to work and I don't understand what I have to do.
I'm currently here:

1. The user has a ticket to App A.
2. The App A makes a request to the server on enpoint /reissue with issueTo to the App B identifier. (The request is authenticated with user ticket.)
3. App A receives a new ticket with app and dlg that reflects the delegation.

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.