Setting course

[Eran Hammer]

I’m doing my best to avoid writing grand essays about Oz and how it’s all going to work. Mostly because I rather just write code. But given that this is now a collaborative effort, I’d like to set expectations and get more people involved.

 

Oz should consist of three main parts:

 

1.      Ticket (what OAuth calls token) generation, validation, and management – this is the area I’ve made some progress on and if you look at the code and the test cases, you can see what it looks like. The current code can issue tickets, validate tickets, and transmit the via the HTTP Authorization header. Still missing is adding grant support (e.g. the user authorization record lookup) and a new way of doing refresh.

2.      User authorization – the “dance” part where the user goes to the provider, authorizes access, etc. This is the part where I’m looking for new ideas. Since Oz is mobile-first, the existing web-view solution that we’ve all learned to hate is just not an acceptable result. We can start with it, but I’d like to come up with new ideas of how to do this. Have you seen better experiences than opening a web-view in your native app? Thoughts about defining a native API for this, so that if you have say, Twitter or Facebook installed on your device, you can directly talk to those services?

3.      Client support – The node module will include an Oz client capable of interacting with any Oz-protected service. But we need at least one native mobile client for iOS or Android for building real test cases. This is the biggest area I’m looking for help.

 

My plan for the next few weeks is to build a working example with both a client and a server and see how the moving parts operate.

 

EH

[Coenraad Loubser]

I love your "speak in code" strategy. It probably means that you have the working parts figured out in your head and the best way to explain them is with code.

However, for someone who's not been working with this stuff... Any pointers to where I can catch up on the state of OAuth, OAuth 2.0 and the 100 other standards - without having to go through all their code too and reading 1000 BS opinions about each? Ie, where's the master cheat sheet, or the table detailing the big picture, the non-acronym flowchart - you know, the one that doesn't use the word "cloud" - so that I can see where I fit into this universe and where I should jump in and throw what little weight I have?...

[Bill Burke]

I don't speak Javascript very well, but I do speak HTTP.  How about a simple page at github that shows examples of exchanged HTTP messages?

[Eran Hammer]

Nah.

 

While I don’t have an objections to someone taking the code and documenting it, I actually don’t want to engage in a technical discussion about how things work if it’s not done in code and pull requests.

 

This is purposely designed to be inclusive to people who are both fluent in implementation details of OAuth 1 and 2, and at the moment, node.js.

 

EH

--
 
 

[Christopher Biscardi]

2/3) On Android there is the AccountManager, which you can use to select accounts on the device (eg: if twitter is installed, multiple twitter accounts can be in the AccountManager).
Seems like the workflow is `getAccountsByType(string)` followed by `getAuthToken(x,x,x,x)`. So that has potential for talking directly to those services.

Apptentative has a nice example of a sort of delegate pattern that could be nice to co-opt into an API.
https://github.com/apptentive/apptentive-android
The "Feedback" button in this app is an implementation of it: https://play.google.com/store/apps/details?id=com.avantdigitalgroup.blackout

I'm imagining a flow like this: 
* User clicks login button
* Window pops up and they can select an account (or potentially log in to a new one?)
* Delegated window gets and returns auth ticket for the chosen account to the app.  Developer can proceed as desired with the ticket.

From the developer's viewpoint it would be:
* Hook up delegate into activity
* Write callback function to be called by the delegate window


I assume there will have to be different implementations for different platforms (iOS, Android, etc).

I have to do more research into the viability of this and dig a bit more into the Oz code. Would love to help out on writing a client or such.

-CB

[justin kruger]

EH if the goal is mobile what other goals do you have?

Would you assume that the user creates the account via mobile and then returns only via mobile, or will the account be accessed/ created in various forms?

If the account is only created on mobile, as we did at Kabam, there are a few interesting things you can do, like skip the password all together.

With iOS there is a Key Store which is unique to your developer ID, and persists between devices.  You could place a ticket in the key store.

Then as the user becomes engaged  If you need to link the accounts later you can always provide an auth link to the user to link the account via copy/paste, access key, or email.  

I also think that key chain follows you from mobile to desktop with your appleId.

I like the notion of an Auth Ticket vs. Token, etc... as it implies something temporary and non-identifying, but authorizing.

I still miss the work that Palm did with Synergy, maybe there are some lessons to be learned there now that WebOS is open source.  ( this might be a good place to prototype these patterns too at the OS level. )

From your talk you seem to want to set priority to Authentication/ Authorization over Identification.  Does that mean that you intend to encourage certificates that authorize roles, rather than identities that contain roles?

On Friday, October 26, 2012 10:45:31 AM UTC-7, Eran Hammer wrote:

[Eran Hammer]

There are multiple goals, but addressing the most common architecture today (native/mobile) is key, which really starts with reducing the role of the application secret and see what follows. It also means moving the direct use of password credentials to the forefront. It is not always practical, but on a native platform, it’s just as secure (or insecure based on your perspective).

 

I think giving a purely mobile experience including account creation is important but outside the scope for Oz. Oz must remain identity-neutral given the two most prominent patterns used today:

 

1.       Username/password provided by the service provider itself

2.       Use of third party identity (Facebook, Twitter)

 

Even if those third parties supported the username/password flow (which is probably unlikely in the short term), that is not going to work with enhanced security measures like 2-factor auth (e.g. Google). But it doesn’t mean we need to give up and stay stuck with the current web-view experience.

 

EH

 

 

 

 

 

 

 

From: oz-pr...@googlegroups.com [mailto:oz-pr...@googlegroups.com] On Behalf Of justin kruger
Sent: Friday, November 9, 2012 11:00 AM
To: oz-pr...@googlegroups.com
Subject: Re: Setting course

 

EH if the goal is mobile what other goals do you have?

--
 
 

[justin kruger]

I think the most secure path is a multi-stage auth, or two factor when it comes to mobile.

The flow might go like this.

* app client request token from API  ( if you want you could use an api key to request the token, this allows you to reject it if you want to later )

* app prompts user for identity, requests new token

* API returns image, or sends 'text message'

* in the case of an image user enters password if they trust the image, password get's hashed with token + time rounded to min

* in the case or txt message user enters pin + password, and pin, token + password are hashed and validated on the server

* return auth ticket/ token, store

* once the app has been identified, you can store the token/ticket + username as a way to auth without the password, allow the token to be rejected, and the api key.

In this way you don't have to ... send passwords in the clear, or rely on https as a solution.  You can also limit replay man in the middle attacks by making sure the password hash is not sent in the clear or the same each time.

The only way to make it more secure than username/password is to base it on a shared memory ( ie the image ), or two factor, ie. txt.

--
--
--
Justin Kruger
Social Media Software Engineer -
San Francisco, CA

--
http://twitter.com/jdavid
http://www.linkedin.com/in/jdavid

[Jan Algermissen]

Hi Justin,

(trying to catch up on security details before I can actively contribute - maybe you can clarify)

On Sunday, November 11, 2012 10:30:55 PM UTC+1, justin kruger wrote:

I think the most secure path is a multi-stage auth, or two factor when it comes to mobile.

The issue with native is the insecurity of the client credentials, correct? IOW, they cannot be used to establish trust?

Eran aims to substitute (for native) the client credentials based signing with something new; something based on the user providing credentials. Correct?

Your proposed flow establishes trust using two factor auth, providing a token for signing via another channel?

 

The flow might go like this.

* app client request token from API  ( if you want you could use an api key to request the token, this allows you to reject it if you want to later )

* app prompts user for identity, requests new token

'requests new token' would be a not-secured request from the client to initiate the two factor auth, not a request for the actual token, correct?

 

* API returns image, or sends 'text message'

'text message' would be e.g. an SMS? Containing the token?

Forgive my ignorance: what is the purpose of returning an image? Can you name an example native app that I can try to see this at work?

 

* in the case of an image user enters password if they trust the image, password get's hashed with token + time rounded to min

* in the case or txt message user enters pin + password, and pin, token + password are hashed and validated on the server

* return auth ticket/ token, store

* once the app has been identified, you can store the token/ticket + username as a way to auth without the password, allow the token to be rejected, and the api key.

In this way you don't have to ... send passwords in the clear, or rely on https as a solution.  You can also limit replay man in the middle attacks by making sure the password hash is not sent in the clear or the same each time.

Ignoring my OAuth novice status for a second, this sounds promising.

 

The only way to make it more secure than username/password is to base it on a shared memory ( ie the image ), or two factor, ie. txt.

Jan

[Robertis Tongbram]

I dont know if this thread is too old to be valid.

I understand the pain when trying to use oauth in native clients especially when the evil app developer can sniff the password from the embedded web view. 

I'm a security noob and this probably doesn't make sense but on the 2nd point( User Authorization) I was wondering, if we can have a generic IDP client library ( ios and android) , where OZ providers can use it and provide an app . So if I'm an end user and want to use an app that uses walmart API, the app forces me to download the walmart IDP app.

So the authZ dance will happen from the 3rd party app to the walmart app and back to the 3rd party app, in the same way Facebook does today using custom url scheme. There will still be some problem with the unique url scheme, as you mentioned in the video, but hopefully Apple will fix it soon. So this way, we can avoid having the users to punch in the userid/password in the 3rd party app. 

Thanks,

Robertis

On Friday, October 26, 2012 10:45:31 AM UTC-7, Eran Hammer wrote:

[justin kruger]

This is based on work I did for socialhelix, a startup way before OAuth existed.  We we never fans of the original spec because of some of the assumed trust that goes on.

The idea is to build trust with the user, the app, and the api over time.

An example of the pattern.

https://www.bankofamerica.com/

1. https session established

2. user enters 'username'

3. asks user history based question

4. server presents the user an image

5. prompts for password

This uses a somewhat simular pattern for a browser based approach.

The text message in a prior example, would be part of a 'User Auth Challenge' pattern that might be 2 factor auth.  The trick is setting up channels  that are easy to use, and not a burden to the user.

There are also different attack vectors to mitigate against.  For instance OAuth2 seems to favor development and minimal state designs over brute force security.

The bigest problem with Mobile is that the limited Pixel Space/ Trusted OS space makes it hard to have extra pixels devoted to  trusted auth on mobile.  Everything is an app, and it's hard to layer multiple apps that can't be faked by the app.  Mobile builds a lot on assumed trust.

--

You received this message because you are subscribed to the Google Groups "oz-protocol" group.
To unsubscribe from this group and stop receiving emails from it, send an email to oz-protocol...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Robertis Tongbram]

 >> Everything is an app, and it's hard to layer multiple apps that can't be faked by the app.  Mobile builds a lot on assumed trust.

I agree. Its easy to fake the real app.

Thanks,

Robertis