I am prototyping HipChat client and I'm stuck at building good authentication experience. I would like to implement similar authentication dialog as HipChat clients built by Atlassian provide. There is no need to generate auth tokens/etc, you just type email/password and client is able to obtain oauth token.
How do they do? Clients use com.atlassian.hipchat.win-clients as client_name in request to https://www.hipchat.com/users/authorize.
Question that I have: how do I register my own client? If I use any random name I get "Named OAuthClient not found ".
How to register client name that will work with any HipChat server, including hipchat.com?
Updated:
I made an example. Please take a look.
https://github.com/chenghuang-mdsol/StandupCat
#VitaliyGanzha
There's a way I used: Build an auth provider based on the integration token.
Make an integration, take down the auth_token.
Use this auth_token on the api here: https://www.hipchat.com/docs/apiv2/method/generate_token
use grant_type 'password', and fill username and password in your post request.
It will return the user info.
Based on the user info it returned, you do your membership provider.
Note that this auth_token has very limited permission. If you want to do more than authentication, you need another personal auth_token which can be generated in your account center.
Tested in C# WCF
Here I've got an answer that it is not possible right now:
This is currently not possible. The flow you described with the
com.atlassian.hipchat.win-clients oauth id is used internally inside
our new desktop and mobile clients. The only other way to obtain an
access token via a 3-legged oauth flow is to create an add-on that you
have to require a HipChat customer to install. Our OAuth tokens are
scoped by group. We don't have allow global tokens. Sorry about that.
https://answers.atlassian.com/questions/32989448/writing-hipchat-client-hipchat-authentication
Related
I'm used to working with ADFS for a long time already and recenlty I was asked to do a proof of concept with Oauth2 on ADFS. Struggling through terminology I managed to set most things up, but still I do have some unanswered questions. Hope someone can shed some light on these...
For SAML / WS-Fed relying parties, it is possible to set custom web content, using Set-AdfsRelyingPartyWebContent. Is this also possible for web api relying parties created in an application group?
Would it be possible to add claims to a client authenticated with client_id / client_secret (server application in ADFS terms) when using the client credentials grant flow?
Even after setting the 'IssueOAuthRefreshTokensTo' 'AllDevices' on the web api application, I still don't receive refresh tokens. What am I missing here?
When posting a token issued by our ADFS on e.g. jwt.io I receive an 'signature validation' error. How can we resolve that?
We would like to set an audience for the access tokens, so applications can use the audience instead of using the appid to verify if they can consume the token. Can we modify the audience?
What does add-adfsclient do? Does it create a client_id, which can then be linked to a relying party (with Grant-AdfsApplicationPermission), thus enabling OAuth2 for an existing relying party?
When configuring a ad user principal for a server application and use 'password' as grant_type with the client credentials grant flow, I cannot seem to find the correct syntax, as ADFS always give the error 'MSIS9622: Client authentication failed. Please verify the credential provided for client authentication is valid.'. I have used the syntax 'user#fqdn' for the username.
Thanks you for helping me out here!
Let me try and work through these.
In ADFS, OIDC applications and WS-Fed / SAML RP are completely different. You can't mix and match.
jwt.io has a signature error because it doesn't know the .well-known endpoint to get the key. Refer this.
To get extra claims you need to add an API as that is the only place for claims rules.
To get a refresh token, you need a scope of "offline_access".
For resource owner password, user name and password are separate fields. Refer here.
Feel free to ask more questions. Just expand your question.
Also, samples here. Look at the menu on the LHS.
Update
What do you mean by "can modify web content on a per relying party basis"?
Re. jwt.io, read this.
For refresh tokens, read this. It seems ADFS doesn't follow the spec here.
Currently working on a service desk application that allows service desk users on our system to see more than they currently can on Jira. What i'm wanting to do is allow them to be able to comment on tickets and possibly add further tickets. I am currently doing this through basic auth, with a 3 legged auth I have made, that uses a jira account to pull tickets for them to see, and then their login to authenticate and then be able to comment on tickets. My issue is that I am having to re-authenticate each time, meaning i have to store the password in a static string somewhere after they have entered it to initially login. I have looked at the api documentation and as far as i can work out Oauth 2.0 is not an option (believe i read that its not supported for customer support desk users), and i cannot get api keys easily for them (if at all) as I would need system admin to generate api keys for all users and then it would be difficult to code.
Storing user password seems wrong, even as a char array. Any help would be massively appreciated!
Storing passwords in active session is not the best method, but it does the Job.
In our application we applied the following:
When user is authenticated the first time Jira sends back a response with a cookie that may look like this:
JSESSIONID=6AD97CC4450456CD968B22F7201220A7; atlassian.xsrf.token=BWP3-NZB2-6EDY-6C7K_d3ec7ed6f227879ac4cf6aee83f28e085e49227b_lin
We stored the user's cookie in their session and we use it every time we send a API request to Jira rest api on their behalf
As cookie is a valid authentication method for Jira service desk api.
Authentication
The JIRA Service Desk REST API uses the same authentication methods as
JIRA. The preferred authentication methods are OAuth and HTTP Basic
Auth (when using SSL). Other supported methods include: HTTP Cookies
and Trusted Applications.
Authentication in Jira Service-desk rest
Proof of Concept
Using postman, send an authenticated request to Jira using basic auth
After getting a 200 response, alter the Authorization in postman and change it from Basic Auth to No Auth and retry the same request.
You should be able to see the same result and if you expand the request headers, you'll find that postman has injected the cookie that was retrieved from the first basic auth request
Hope this helps.
By reading Cognito Identity Provider document, I understand that it looks like it provides out-of-box integration with Facebook / Google / Twitter as Identity Providers.
My application is a developer focused application so I would like enable users sign-up/sign-in with their Github account besides the above Identity Provider's accounts. Is that possible?
If possible, how much extra work (comparing the out-of-box Facebook/Google social sign-up feature) I need to do?
Since first writing this answer, I implemented and published a project that provides a wrapper for Cognito to talk to GitHub. It comes with a SAM/cloudformation deploy script, so you can create a CloudFormation stack that provides the wrapper very easily.
So, OpenID Connect is built on top of OAuth2.0. It's an extension - in OpenID Connect, the OAuth endpoints are there (with one or two extensions or changes), plus some new endpoints.
My understanding from reading the Cognito documentation and the relevant bits of the OpenID Connect and OAuth2.0 specs is that Cognito only uses four of the OpenID endpoints - Authorization, token, userinfo and jwks. You can specify each endpoint separately when configuring an OpenID Connect provider in Cognito. This means it is possible to provide OpenID Connect for github by implementing these endpoints.
Here's a rough plan for implementation:
Authorization: In the spec, this looks to be the same as the OAuth2.0 endpoint (plus some additional parameters that I don't think are relevant to using github as an identity provider). I think you could:
Use the github Auth URL: https://github.com/login/oauth/authorize
Set your GitHub OAuth app to redirect to https://<your_cognito_domain>/oauth2/idpresponse
For the other endpoints, you'll have to roll them yourselves:
Token: This is used to get the access and ID tokens - using a code returned by the authorization callback. It looks the same as the OAuth2.0 endpoint, but also returns an idToken. It looks possible to make an implementation that passes through the code to github's token endpoint (https://github.com/login/oauth/access_token) to get the accessToken, and then generates an idToken, signed with your own private key.
UserInfo: This doesn't exist at all in OAuth2.0, but I think that much of the contents could be filled in with requests to the /user github endpoints (since at this point the request contains the authenticated access_token). Incidentally, this is the reason that there's no open source shim to wrap OAuth2.0 with OpenID connect - OpenID connect's primary contribution is a standardised way of communicating user data - and since OAuth doesn't have a standardised way to do this, we have to write a custom one specific to GitHub (or any other OAuth-only provider we wanted to use for federation).
JWKS: This is the JSON Web Key Set document containing the public key(s) that can be used to verify the tokens generated by the token endpoint. It could be a flat file.
I have implemented the above, and the approach works. I open-sourced the project here.
Unfortunately it's not possible. Cognito Federated Identities can support any OIDC Identity Provider but OAuth2.0 spec does not give that flexibility, so there's no easy way to achieve this unless we add special support for Github.
I'm about to start working on application with rest API and I want to use apigility. There is one problem unfortunately with this idea. I cannot find reliable source of information how to allow for authentication by oAuth for regular users.
I need to provide access for angular app and native mobile one (possibly in future for third-party web apps). All resources that I have found are about granting access to api for specific client application, not for specific users that use this applications. I don't want to implement two different authentication methods, so if there is a way to resolve this issue with apigility it would be great.
Do you have any suggestions how to approach this? I know that I can generate client id and secret for all registered users but this seams a little crappy solution and I have database schema already in place for storing user info.
What you're likely looking for is the "password" grant type. In this scenario, you will have a way of registering users and their passwords, and then a "login" screen of sorts. This login screen will send the following information:
username
password
client_id -- this will be the OAuth2 client ID (not the user ID!) for the application
"grant_type": "password"
Note that you are NOT providing the client_secret in this scenario! In the case of a user credential scenario, the user's credentials are validated, and then the server verifies that the client_id supports this grant type.
If the user provides successful credentials, then the OAuth2 endpoint will return a token, a TTL, and a refresh_token (which, if you send it before the TTL expires, will give you a new set of tokens).
From here, you will then send the token in the Authorization header: "Authorization: Bearer ". Apigility will then pick this up on each request and validate the token.
The validation returns also the username as part of the identity. This means that you can query the ZF\Mvc\Identity to retrieve the user in order to perform user-specific ACL assertions later!
Poke me on the mailing list (http://bit.ly/apigility-users) if you need some more direction.
Hello kind people of the internet.
Does Google OAuth2.0 support an OAuth-flow for a Resource Owner Password Credential Flow?
...and if so, then:
A.) can this type of OAuth flow be tested on the Google OAuth2 Playground?
B.) are there any examples of the "Resource Owner Password Credential Flow" with Google OAuth2.0 and the Google APIs?
Per an OAuth presentation recently in Oslo NDC 2013, this subject flow apparently skips the authorization end point all together and directly talks to the token end point of the OAuth2 server. The request syntax incantation would supposedly look something like this:
grant_type=password&
scope=resource&
user_name=owner&
password=password&
My understanding is the Resource Owner Password Credential Flow is for trusted applications in a back-end enterprise type of situations (where a name-password pair could be securely stored).
This particular OAuth flow would require no end-user consent interaction (no pop-up of a browser to Accept, then get a returned authorization-code, etc). In this subject flow the access & refresh token are directly returned, again: with no end-user interaction (albeit after an entry of a username-password).
Looking through the Google OAuth documentation ( link to Google OAuth2 docs ) there does not seem to be any mention of anything resembling Resource Password Credential Flow, but not sure that necessarily means it is explicitly not supported by Google.
Any help or advice would be much appreciated.
thanks in advance
Dear kind internet person,
it is true that Resource Owner Password Credential Flow is not supported on Google but google suggests you use the Installed Application Flow, which is described in: https://developers.google.com/accounts/docs/OAuth2InstalledApp.
You would need to create an Installed Application in the Google Console (https://code.google.com/apis/console), when you do that you can fetch the client_id and build a GET request with the parameters, which would look like so:
https://accounts.google.com/o/oauth2/auth\?
scope\=<scope>\&
redirect_uri\=urn:ietf:wg:oauth:2.0:oob\&
response_type\=code\&
client_id\=<client_id fetched from google console>
You would construct this URL and navigate to it on your browser, allow access for the app and google would give you what I believe is a code which you can use to get credentials. You can use those credentials to get an access token and refresh it, and this credentials is permanent. There's a good example of that on github. Note that you only need to get those credentials manually once, and then you save those credentials somewhere and keep using them to get/refresh tokens.
Hope this helps!
As far as I know, No. The OAuth 2.0 stuff is for Google accounts, for which Google does authentication.