OAuth REST API authentication

[Jorge Ruesga]

Hi,

Are there any plans to support some sort of OAuth2 via rest api? Just some sort "connected apps" for the user profile, so developers can request to Gerrit site admins an app client secret to start an oauth2 auth flow, and users having the availability of revoked apps access_tokens, and maybe with grained access permissions via scopes.

Regards

[Edwin Kempin]

On Mon, Dec 25, 2017 at 10:14 PM, Jorge Ruesga <j.ruesg...@gmail.com> wrote:

Hi,

Are there any plans to support some sort of OAuth2 via rest api? Just some sort "connected apps" for the user profile, so developers can request to Gerrit site admins an app client secret to start an oauth2 auth flow, and users having the availability of revoked apps access_tokens, and maybe with grained access permissions via scopes.

There are 2 oauth authentication provider plugins [1]. Maybe you can use one of them?

[1] https://gerrit-review.googlesource.com/Documentation/config-plugins.html#oauth-authentication-provider 

Regards

--
--
To unsubscribe, email repo-discuss+unsubscribe@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[luca.mi...@gmail.com]

Hi believe Jorge referred to Gerrit itself being an OAuth 2.0 provider to verify identities and grant access tokens.

Gerrit has no mechanism for verifying identities but delegates that task to an external authentication system.

The plugins Edwin mentioned are for consuming tokens from other Auth 2.0 providers.

HTH

Luca

Sent from my iPhone

To unsubscribe, email repo-discuss...@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.

[Jorge Ruesga]

Hi,

Luca, not not necessarily "Gerrit itself being an OAuth 2.0 provider". There are many REST api services (xe feedly) relaying on external OAuth2 providers to provide authentication to its rest api clients. Basically, it have a rest api oauth end point that provides the necessary workflow to obtain an access and refresh token.

My main concern with this request a way to login in IOS/Android apps without the need to store user authentication locally in the phone. The current oauth plugins only provides authentication for the Gerrit website itself, but no way to obtain access_token and refresh token. With the current OAuth flow, one can create a Webview and try to obtain the XSRF_TOKEN cookie to provide the X-Gerrit-Auth header, but:

1.- This token is websession based, so it will expire at some point, which requires present a new oauth flow window to the user to login again (which seems to be a good UX behaviour to me).
2.- Embeeded browsers (aka webviews) are disable by Google Sign since April 1 (https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html), basically to about app developers to access cookies or change the response (basically allow developers some kind of phising).

And in the way, this could enable fine grain access to api via scopes, like let an access_token to do read operations (like read changes), disallowing publish comments or changes, or not allowing to access user account details like secondary emails, etc. Also, user can get control which apps are connected and revoke its accesses.

In addition the current http password is one-way generated, that means if i have 2 devices the user needs to generate the http password, store outside Gerrit and type ion both devices (or even between different apps on a same device), which sounds a bit unsecure.

Regards

[Luca Milanesio]

On 29 Dec 2017, at 08:49, Jorge Ruesga <j.ruesg...@gmail.com> wrote:

Hi,

Luca, not not necessarily "Gerrit itself being an OAuth 2.0 provider". There are many REST api services (xe feedly) relaying on external OAuth2 providers to provide authentication to its rest api clients. Basically, it have a rest api oauth end point that provides the necessary workflow to obtain an access and refresh token.

The fact that Gerrit starts managing access tokens and refresh tokens, means that it will need to become a kind-of "provider" of authenticated identities, even if those are then delegated to another external OAuth 2.0 provider for validation.

It would then act as OAuth 2.0 proxy is some way.

Are you thinking about something like JWT and Auth0?

My main concern with this request a way to login in IOS/Android apps without the need to store user authentication locally in the phone. The current oauth plugins only provides authentication for the Gerrit website itself, but no way to obtain access_token and refresh token. With the current OAuth flow, one can create a Webview and try to obtain the XSRF_TOKEN cookie to provide the X-Gerrit-Auth header, but:

1.- This token is websession based, so it will expire at some point, which requires present a new oauth flow window to the user to login again (which seems to be a good UX behaviour to me).
2.- Embeeded browsers (aka webviews) are disable by Google Sign since April 1 (https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html), basically to about app developers to access cookies or change the response (basically allow developers some kind of phising).

I doubt that what you need is in the scope of Gerrit: why don't you just use Auth0?

And in the way, this could enable fine grain access to api via scopes, like let an access_token to do read operations (like read changes), disallowing publish comments or changes, or not allowing to access user account details like secondary emails, etc. Also, user can get control which apps are connected and revoke its accesses.

If you use something like Auth0 you can definitely do that. By managing the ownership to groups you can then control the permissions using Gerrit ACLs.

Access to e-mails though is not something it is currently controlled via ACLs and won't be available.

In addition the current http password is one-way generated, that means if i have 2 devices the user needs to generate the http password, store outside Gerrit and type ion both devices (or even between different apps on a same device), which sounds a bit unsecure.

Agreed, using HTTP passwords is not the way to access securely from a mobile device.

Regards

--
--

[Jorge Ruesga]

My concerns was more from an app developer point of view. I have an android app that provides access whatever gerrit instance the user want to access, but I don't control any of them. Auth0 could be implemented in a Gerrit site but other gerrit instances could implement other OAuth solutions, and I'm not sure all be compatible (one could be oauth1a or something like that). In fact, currently I have no way to know if the gerrit instance allow an oauth app client workflow. I was trying to request some more integrated into Gerrit code solution.

Regards

[Luca Milanesio]

On 29 Dec 2017, at 09:50, Jorge Ruesga <j.ruesg...@gmail.com> wrote:

My concerns was more from an app developer point of view. I have an android app that provides access whatever gerrit instance the user want to access, but I don't control any of them.

I see, then you cannot just assume that Gerrit is configured with an OAuth 2.0 or Auth0 either.

Auth0 could be implemented in a Gerrit site but other gerrit instances could implement other OAuth solutions, and I'm not sure all be compatible (one could be oauth1a or something like that). In fact, currently I have no way to know if the gerrit instance allow an oauth app client workflow. I was trying to request some more integrated into Gerrit code solution.

I believe it is quite challenging from your perspective to manage *any possible authentication system* that a Gerrit server has configured.

You may have:

- LDAP

- HTTP

- OAuth 2.0

- SSO with SAML or similar

- X.509

- SSH

... or any other "thing" you could plug into an HTTP reverse proxy

Are you developing an OpenSource Mobile client for Gerrit?

Are you aware of https://gerrit.googlesource.com/apps/reviewit/ ? It is an Android Gerrit Client that provides the code-review experience on your Mobile phone.

Luca.

[Jorge Ruesga]

Are you developing an OpenSource Mobile client for Gerrit?

Yeah, I developed/mantained an Android one (https://github.com/jruesga/rview). It's almost paired in featured with the Gerrit web.

 

Are you aware of https://gerrit.googlesource.com/apps/reviewit/ ? It is an Android Gerrit Client that provides the code-review experience on your Mobile phone.

Yes, I'm aware of it

[Luca Milanesio]

On 29 Dec 2017, at 10:52, Jorge Ruesga <j.ruesg...@gmail.com> wrote:

Are you developing an OpenSource Mobile client for Gerrit?

Yeah, I developed/mantained an Android one (https://github.com/jruesga/rview). It's almost paired in featured with the Gerrit web.

Very nice App ... do you have (or are you planning) an iOS one as well?

I see your point of doing the authentication once and get an access token for it. I believe the only thing you could do is really to "simulate" a web login (POST to /login) and getting the resulting Cookies. Then store the cookies and keep them as much as you can.

 

Are you aware of https://gerrit.googlesource.com/apps/reviewit/ ? It is an Android Gerrit Client that provides the code-review experience on your Mobile phone.

Yes, I'm aware of it

[Jorge Ruesga]

Very nice App ... do you have (or are you planning) an iOS one as well?

Seems Paladox beats you on the request ;) https://github.com/jruesga/rview/issues/37 (no planning on ios app for now)

 

I see your point of doing the authentication once and get an access token for it. I believe the only thing you could do is really to "simulate" a web login (POST to /login) and getting the resulting Cookies. Then store the cookies and keep them as much as you can.

Yeah, that's works for HTTP basic auth, but is more complicated for oauth.

Thanks for your suggestions Luca.

[Luca Milanesio]

Yes, you basically need to embed in the APP the support for the external OAuth authentication handshake.

As you said, typically this was done in an in-app browser window. Alternatively, you could include in the App the support for the OAuth provides Gerrit has support for (GitHub, GitLab, Bitbucket and a few others) and manage the redirection transparently in the app.

Thanks for your suggestions Luca.