This question already has an answer here:
Handling JWT bearer token from ADFS
(1 answer)
Closed 1 year ago.
We have a basic use case to connect to webserver and get an ack back but having issues in Authentication.
Scenario : Feature sample
Given url <>
And header Content-Type= 'application/json;'
And header AuthScheme='KEBEROS' #hasnt helped though
When request <>
And method POST
Then status 200
Error in logs:
'You were not able to be authenticated using SPNEGO'
I have tried few options to add VM arguments for KRB5 but didnt seem to help.
Let me know if any else faced this and how you handled this in config. We are checking the option to have a custom class for http but wanted to check if any property can be defined correctly above or in config.
As long as you can figure out the right cookies and headers, you should be able to get it to work.
Also refer this answer: https://stackoverflow.com/a/51150286/143475 - yes, it is possible you need to depend on some .NET code to get you the token, but there are various ways to do this.
Note that for the sake of testing, you could consider standing up a service only for testing in your intranet - that will give you the right "magic" header that is needed.
And note that Karate can do browser-automation, so if it means you need to perform a sign-in using a browser and get the cookies, consider that: https://github.com/intuit/karate/tree/master/karate-core
Related
I'm kind of surprised that, after searching for this for a while, I didn't find as many answers as I thought would be out there (well I found none), so maybe by asking it here we can help improve search results.
I'm building a REST api which has JWT-based authentication. There is an /auth/login route which returns the token after login/password verification, and the token is subsequently sent in every route in a Authorization http header.
Not, suppose that someone queries another route (say, /cars), without sending the token (that is, before logging in). If I return a 401 unauthorized, I can make the frontend query /auth/login to get the token.
But, strictly speaking, this does not conform to the REST specification, because every resource should be discoverable from the initial one, and a client accessing /cars and receiving a 401 will not know about /auth/login.
So another option would be a redirection like 302. But this semantics means that the resource was temporarily moved, and this is not the case (the resource is still /cars, you just need to authenticate first).
So, what is the correct way to do this procedure in a "true" rest api?
I 100% agree, and that's why I proposed this standard:
https://datatracker.ietf.org/doc/html/draft-pot-authentication-link-01
The idea is that for cases like this, you should be able to return a Link header with an authentication rel, so the client can discover how to proceed.
I know there is enough content for this question on the Stack Overflow but my subject is not the same as the others. ( Kinda the same but not equal )
I want to hear the community thoughts of what I doing and to see if I can improve somewhere or not.
I'm currently using BASIC Authorization for my login EndPoint as it doesn't require complexity and its over https so its fine the way it is.
Example:
GET - /api/login
Authorization : Basic BASE64String(username:password)
Some of my EndPoints require Tokens to be granted access to the resource. These Tokens I'm sending trough Headers and Https-Secured.
The thing is I'm not using a conventional method of doing these Authorizations. Some examples below:
Example 1:
GET - /api/hardware/{PUBLIC_TOKEN}/getMe
Authorization-Hardware : PRIVATE_TOKEN
This EndPoint doesn't require the Authorization-Hardware Header, but if included more things are done by the API. ( Not relevant here )
Example 2:
GET - /api/login/{id}
Authorization-Person : USER_TOKEN
This EndPoint otherwise is necessary including the Authorization-Person Header with the User Token to access the resource. ( Note that how the Token is generated is irrelevant here )
To access the API EndPoints an HTTPS request is necessary.
I gave arbitrary names to the Custom Headers and EndPoints above just to give a picture of what my Authorization Schema is, the names doesn't match the original ones. So don't bother the names just foccus on the schema.
My question is: Not following the convetional way is such a bad thing ? Creating Custom Authorization Headers is bad somehow ( if it is why ? ).
I find this way simpler to give Authorization and a secure way of passing tokens, all these Tokens can be re-generated in the platform again.
Lots of devices and a Mobile Application is already using this Schema, but its all under Development Environment and its not in Production yet. My fear is that this non-conventional way of doing this can affect users of the API in the future. Hope the community thoughts can help me to improve this.
EDIT: 26/03/2017
I would like to know if it would be better and why implementing in the way that is described in the protocol, as its harder to fetch from the Headers when multiple Authorizations is required than when you have a Custom Header and wants to retrieve its value.
Following the Protocol you should use Authorization Header like this:
Authorization: <type> <value>
Example:
GET - /api/login/{id}
Authorization : User USER_TOKEN
But I just can't see what I gain following this, because when fetching its value would come a String or in the example case it would return User Token.
Using an Custom Header its way easier validating the Token. Multiple Authorizations can give a headache too following the protocol way.
TL;DR Some header names such as Authorization have special rules about caching as well as proxy & client handling; your custom header names would not get the special behavior unless you modified every single proxy & client.
The point of using the common Authorization: <type> <value> header as defined in RFC7234 is mostly to ensure that clients & HTTP proxies that natively implement handling of those headers behave CORRECTLY.
Section 4.2 of RFC7234 says:
A proxy forwarding a request MUST NOT modify any Authorization fields
in that request. See Section 3.2 of [RFC7234] for details of and
requirements pertaining to handling of the Authorization field by
HTTP caches.
The Proxy may modify, omit, log or cache your other Authorization-* headers.
RFC7234, section 3.2 says that requests/responses Authorization header MUST not be cached (except in specific circumstances).
RFC7235, section 5.1.2, point 7 furthermore has this say to about NEW authentication schemes that use headers other than Authorization:
Therefore, new authentication schemes that choose not to carry credentials in the Authorization header field (e.g., using a newly defined header field) will need to explicitly disallow caching, by mandating the use of either Cache-Control request directives (e.g., "no-store", Section 5.2.1.5 of [RFC7234]) or response directives (e.g., "private").
So what should you do...? If you controller both ends of the system entirely, it's not unreasonable to define a new type value that might have multiple parameters to cover any combination of one or more token types, just avoiding the , character:
Authorization: MyAuth User=USER_TOKEN/Hardware=HWTOKEN/Person=PERSONTOKEN/Basic=...
The alternative depends on server & client implementations more, and would be using a , as the alternate version list form of multiple headers:
Authorization: User USER_TOKEN, Hardware=HWTOKEN, Person=PERSONTOKEN, Basic=...
Which depending on the server & client, may be treated the same as:
Authorization: User USER_TOKEN
Authorization: Hardware HWTOKEN
Authorization: Person PERSONTOKEN
Authorization: Basic ...
The problem here is "MAY" (lots of added emphasis) be treated the same. There's discussions suggestion that various versions of Apache & NGINX don't treat this consistently, and that the older HTTP RFCs are very unclear about the intended behavior.
I'm implementing the Socrata API to be able to parse publicly-available data from the City of Chicago open data set. I am really just concerned about the data itself, so I did not initially think that I would need to implement OAuth2 through an app exposed via ngrok to be able to GET the data.
My initial attempt was to take the GET requests mentioned in their documentation and try to get responses through Postman.
Here's an example of such an attempt:
I also added my Socrata App Token as a param in the querystring, but the same message was shown.
So I tell myself, ok, maybe they deprecated GET requests without making the client go through OAuth2. If they didn't deprecate these GET requests, I would prefer not to have to deal with OAuth2, but I began implementing the authentication process and everything went successfully until I got to the following instructions found here:
I have every single value that needs to be included in that POST request except for 'authorization_type'. Where does this come from? I tried leaving 'authorization_type' in as a string, but received a response similar to the 'Invalid username or password' message in the top image in this question.
Are you only accessing public datasets from Chicago's data portal? From your screenshot it looks like you're trying to access the Building Permits dataset, which is public.
Authentication is only required for modifying datasets or accessing private data, so chances are very good you don't even need to authenticate. Just include an application token with your request for throttling purposes.
Glad to help you figure out your OAuth workflow, but it sounds like it might be unnecessary.
I want to get work log of a specified issue on Jira. According to this document https://docs.atlassian.com/jira/REST/latest/#d2e774 I'm using this format giving my issue id:
/rest/api/2/issue/{issueIdOrKey}/worklog
Although I have logged in Jira, I got this error:
{"errorMessages":["You do not have the permission to see the specified issue.","Login Required"],"errors":{}}
Besides, I can see work log on Jira's interface. I don't think there is an permission constraint. Any help to solve?
You REST API request need to be authenticated. Please read Authentication paragraph (4th from the top): https://docs.atlassian.com/jira/REST/latest/
The easiest way is to use /rest/auth/1/session: https://docs.atlassian.com/jira/REST/latest/#d2e3737
I hit this issue when trying to use Cookie-Based authentication, I was following this guide from Atalassian; https://developer.atlassian.com/jiradev/jira-apis/jira-rest-apis/jira-rest-api-tutorials/jira-rest-api-example-cookie-based-authentication
The guide mentions the need for JSESSIONID but does not mention you'll also need to supply studio.crowd.tokenkey, really check what cookie elements you get back when you authenticate in case they change it again, and don't update documentation.
For my own sake I noted down all the code here.
Okay, so we are building an iPhone app to hit a Sharepoint 2013 site that is hosted on Office 365. If I were building this in C#, which I've already done, I would have the luxury of just using TokenHelper.cs to get me most of the way there. Unfortunately, as far as I know, there is no TokenHelper for Objective-C yet.
So here's the deal, we can already successfully get the OAuth authentication/authorization page to come up and we successfully get an Authorization Code back.
After this point we were stumped for a bit because we knew that we were missing the realm id in the POST for obtaining our Access and Refresh tokens. I finally figured out how TokenHelper does this and we've duplicated that. (This was an additional call to /_vti_bin/client.svc where you expect to get a 401 so that you can pull the realm id out of the header)
We now have a realm id that, from what I've read in documentation and TokenHelper and seen in Fiddler, needs to then get used in the following 2 ways: within the URL construction for the POST as well as for the resource value in the header for that POST.
So the POST url looks like this:
accounts.accesscontrol.windows.net/{realm id}/tokens/oauth/2
Our resource value looks like this:
resource=00000003-0000-0ff1-ce00-000000000000%2f{realm url}%40{realm id}
This at least connects fine and accepts our POST. Unfortunately, we are getting the following message back:
ACS50012: Authentication failed. ACS90011: The realm '' is not a configured realm of the current service namespace.
This message makes me think that there may be a configuration issue, but I really can't be sure.
Has anyone else tried performing OAuth against a 365 site yet within Objective-C and had success?
I can post code as well, but I was trying to shy away from that initially.
I recently came across the same problem and have a feeling it may be the same issue you are seeing.
The correct POST request for OAuth is as follows:
POST https://accounts.accesscontrol.windows.net/<REALM_GUID>/tokens/OAuth/2
x-www-form-urlencoded params:
grant_type:authorization_code
client_id:<CLIENT_ID>#<REALM_GUID>
client_secret:<CLIENT_SECRET>
code:<AUTH_CODE>
redirect_uri:<REDIRECT_URI>
resource:00000003-0000-0ff1-ce00-000000000000/<SHAREPOINT_AUTHORITY>#<REALM_GUID>
The major gotcha for me was that the value of the "client_id" required the realm id appended to the client id. Not including the realm id will throw an "ACS90011: The realm '' is not a configured realm of the current service namespace."
HTH