I am currently working on my own ACME client implementation.
I generated the following JWS:
{"protected": "ewogImFsZyI6ICJFUzI1NiIsCiAiandrIjogInsia3R5IjogIkVDIiwiY3J2IjogIlAtMjU2IiwieCI6Ik1UYzVOVFF6TVRJME16STNNamd5TVRjM01UZzFOVFV5TnpJME16a3hOalk0TURjM01UYzNNalV3TWpJeU5qVXpNVFk0T1RRMU1ETTRNRFV5T0RRd09UY3dOemd6T0RFMU1qQTQiLCJ5IjoiTXpjeU56UTFNVEkyTURVME9EQTROREE0TXpBek9URTBNVGczTXpFME5UWXhORGcwT1RrMk5EUTFNRGswTVRNek5USTFNRGcxTmpZek9ERTRPRGsyTnpVNE1EZzROell6T1RJME9ETSJ9IiwKICJub25jZSI6ICI5aUxqYUdIMEV0R2NySDBLdDF0MTBBIiwKICJ1cmwiOiAiaHR0cHM6Ly8wLjAuMC4wOjE0MDAwL3NpZ24tbWUtdXAiCiB9","payload":"eyJ0ZXJtc09mU2VydmljZUFncmVlZCI6IHRydWV9","signature":"MEUCIFNRj1eVStlonvZhEzg92Bb57qZn3wEUi2dvwdWFQ3oaAiEAg5BQKHeGip0kcv8dEbfnhZCrgb11myFztxfIOWtdvVs"}
Signed with ES256 (ECDSA P256 and SHA256)
Public Key X: 179543124327282177185552724391668077177250222653168945038052840970783815208
Public Key Y: 37274512605480840830391418731456148499644509413352508566381889675808876392483
JWK: {"kty": "EC","crv": "P-256","x":"MTc5NTQzMTI0MzI3MjgyMTc3MTg1NTUyNzI0MzkxNjY4MDc3MTc3MjUwMjIyNjUzMTY4OTQ1MDM4MDUyODQwOTcwNzgzODE1MjA4","y":"MzcyNzQ1MTI2MDU0ODA4NDA4MzAzOTE0MTg3MzE0NTYxNDg0OTk2NDQ1MDk0MTMzNTI1MDg1NjYzODE4ODk2NzU4MDg4NzYzOTI0ODM"}
Unencoded Headder:
{
"alg": "ES256",
"jwk": "{"kty": "EC","crv": "P-256","x":"MTc5NTQzMTI0MzI3MjgyMTc3MTg1NTUyNzI0MzkxNjY4MDc3MTc3MjUwMjIyNjUzMTY4OTQ1MDM4MDUyODQwOTcwNzgzODE1MjA4","y":"MzcyNzQ1MTI2MDU0ODA4NDA4MzAzOTE0MTg3MzE0NTYxNDg0OTk2NDQ1MDk0MTMzNTI1MDg1NjYzODE4ODk2NzU4MDg4NzYzOTI0ODM"}",
"nonce": "9iLjaGH0EtGcrH0Kt1t10A",
"url": "https://0.0.0.0:14000/sign-me-up"
}
Unencoded payload:
{"termsOfServiceAgreed": true}
This account creation request is rejected by the ACME Server (Pebble) with the following response:
{
"type": "urn:ietf:params:acme:error:malformed",
"detail": "Parse error reading JWS",
"status": 400
}
Can someone please have a look? Thanks in advance.
M
I tried changing formats a lot but nothing works.
Looking at your unencoded header, I can see that the jwk value starts and ends with a double-quote (i.e., the character '"'). An example in RFC 8555 (page 35) shows that the jwk value is not a string, so this might be the problem. Using a JSON object instead of a string might work.
Related
I am creating a Power Automate flow to get MS Booking information. Having trouble with getting an Authorization using https://login.microsoftonline.com/***TENANT ID****/oauth2/token. I receive an error that I am missing grant_type although I supply it. I registered the app in azure, the HTTP request in power automate looks like this:
{
"uri": "https://login.microsoftonline.com//oauth2/token",
"method": "POST",
"headers": {
"content-type ": "application/x-www-form-urlencoded"
},
"body": "client_id=&resource=https://graph.microsoft.com&grant_type=password&client_secret=&username=username&password=password"
I receive the error:
{"error":"invalid_request","error_description":"AADSTS900144: The request body must contain the following parameter: 'grant_type'.
Anyone have an idea what I am doing wrong or missing? Thank you in advance.
Just a quick follow-up. Thanks Expiscornpvus, you pointed me in the right direction, although there were spaces after the content type header, I corrected this and things worked well
I was decoding a JWT token via jwt.io (in the Debugger section) to see Headers, Payload. Surprisingly, it also verified, and I could see it (jwt.io debugger) is able to retrieve the public key as well.
So my question is: Does JWT token provide the public key as well as part of the JWT token?
I am pasting part of it (can't paste full due to security reasons, will be truncating part of the actual JWT token)
F3cy5jb21cL2V1LXdlc3QtMV9ZckVRYjY5Z1giLCJleHAiOjE2MDE2Mzg4OTMsImlhdCI6MTYwMTYzNTI5MywidmVyc2lvbiI6MiwianRpIjoiNmI2YmZiNmYtY2M0MS00N2Q5LWI0YzYtOTBmOGFmNWM2MjQ1IiwiY2xpZW50X2lkIjoiMTM0MWxxa3N1ZmUwbm1vaW9kdnRjc2t2cWIifQ.RtKfz54uBgSZ1gc4KRPjzL4dPe5AbH2YMJu-DDvIxBzgMjqT9q4ApGzcWYB62-MgDUf-F_hK0kF9eIwAi9fARhp 0HGGnyiuydW_our6zE3EphLvXQByTDY5xzOUuSvt7WbDZWeSfpHcjrBttRSJAPOsZ2gInafKjZgWKyGL4vJB9swEhOMSSpTQDGWKenJCyp4emhe8E4XGzYTo9WEb-Wqg6sI__LrusDNd917FaocPKBxA
Decoded messages (again truncated)
Headers
{
"kid": "cJ0PzkBXPyjX7FM67jcOECIY=",
"alg": "RS256"
}
Payload:
{
"sub": "13lqs0moiodvtcskvqb",
"token_use": "access",
"scope": "example.com/Manage",
"auth_time": 1601293,
"iss": "https://cognito.eu.amazonaws.com/",
"exp": 1601638,
"iat": 10353,
"version": 2,
"jti": "cc1-47d9-b6-5c6245",
"client_id": "nmodvtcb"
}
In there, can see the Public key (truncated)
-----BEGIN PUBLIC KEY-----
QEFAAOCAQ8AMIIBCxmf9bakWk
556KYmIZB+Sy1ftkkGa4qlUsmRvcG2Hll+7HBWp1ao6MVLskjdaaKg8iH1Iz4DKG
lgqT/ndwhoxvTBuvm0X2CZoNzZn4S8wDTr78m/S/YegZRhv6y58gkiKSEmbbC/g5
Bp+AF88NwBvLm1jdd
-----END PUBLIC KEY-----
Where from the debugger in jwt.io is retrieving the public key? I am not able to understand this.
The token contains the issuer (iss) of the token and the key id (kid), which identifies the public key that is needed to verify the signature
With this information, jwt.io can find the public key in form of a JWK (JSON Web Key) on a JWKS endpoint (/.well-known/jwks.json), to verify the token. A JWKS (JSON Web Key Set) contains an array of JWKs, the link shows an example.
According to the cognito documentation, this mechanism is used, when you use the Amazon user pool to authenticate your users.
Providing keys via a jwks endpoint is a standard mechanism which is also used by other providers, e.g. Microsoft Azure.
I've been trying to understand that myself too. If you open developer tools and see requests made by jwt.io when you paste the token in the debugger page you'll see it makes additional requests.
In my token the iss was:
"iss": "http://localhost:8080/auth/realms/myrealm"
hence jwt.io added the standard path /.well-known/openid-configuration and made XHR request to
http://localhost:8080/auth/realms/myrealm/.well-known/openid-configuration
Where it found a lot of information in json and among them there was jwks_uri
{
...
"jwks_uri": "http://localhost:8080/auth/realms/myrealm/protocol/openid-connect/certs",
...
}
And then there was another XHR request to the above url and response was jwks.
Having that public key the jwt.io could verify the token. At least that's what I think happens.
I am trying to call https://graph.microsoft.com/v1.0/planner/tasks/{{taskId}}/details with this request:
{
"checklist": {
"552f6163-e7d3-4e31-9015-577b0e6cc997": {
"#odata.type": "microsoft.graph.plannerChecklistItem",
"title": "Update task details",
"isChecked": false
}
}
}
I have the if-match header set properly, with the etag from the tasks. I get the below 400 Bad Request response when I run the query:
{
"error": {
"code": "",
"message": "The input is not a valid Base-64 string as it contains a non-base 64 character, more than two padding characters, or an illegal character among the padding characters. ",
"innerError": {
"request-id": "c9781050-e409-4b88-9d7e-0a57dcec1f82",
"date": "2020-05-29T21:26:17"
}
}
}
I have tried random GUIDs, and base-64 encoded strings, to no avail. I also tried to download the Postman Environment, but I get the same error from there. Any help or guidance would be hugely appreciated.
Thanks for your time.
B.
You are getting this error because the If-Match header has an invalid value. When viewed by tools, sometimes tools include escape characters, which needs to be adjusted when making queries manually through Graph Explorer or Postman. Correct If-Match header value looks like:
W/"Base64EncodedStuff"
Aside from that issue, your query appears correct.
When i am searching for emails on office 365 in a batch query, i am getting a unterminated string literal error. This is happening only when i have a # character in the subject search query.
Forum discussions like this (https://issues.oasis-open.org/browse/ODATA-1101) have suggested me to percentage encode the # symbol but it gave the same error.
When I am POSTing the below request to the batch endpoint(https://graph.microsoft.com/v1.0/$batch)
{
"requests": [{
"id": 1,
"method": "GET",
"url": "/users/somemailbox#mytenant.onmicrosoft.com/messages?$select=id,internetMessageId,toRecipients,ccRecipients,bccRecipients,subject,isRead,sender,receivedDateTime&$top=500&$search=\"received>=2019-06-19 AND (subject:\\\"PO# 123\\\" AND from:email#domain.com)\""
}]
}
I get this error
{
"responses": [
{
"id": "1",
"status": 400,
"body": {
"error": {
"code": "BadRequest",
"message": "There is an unterminated string literal at position 39 in '\"received>=2019-06-19 AND (subject:\\\"PO'.",
"innerError": {
"request-id": "801078a5-d3c6-4b93-a152-6653a3d8ca44",
"date": "2019-07-22T06:29:16"
}
}
}
}
]
}
Can you guys please help me with fixing my search query?
Thanks,
Ashish
The # character is used to delimit fragments in a URL, which are intended to represent client side state. Browsers will generally not send the # or anything following it, and servers will generally ignore it if it's sent accidently.
Your issue is most likely an encoding one - depending on how you're encoding the query string the # might be getting left alone, when in actuality you want it to be encoded to %23.
Whenever I try a post a complex character to create a list entry in an O365 SharePoint list (via REST API) I get a JSON parse error from the server. The following is the simple post and it is the β (beta) character which causes the fail. &mdash (—) and other non-simple characters also cause the fail.
The code works just fine for alphabetic characters. It appears to me to be a parsing issue on the SharePoint side but I wanted to know if I was missing something stupid (it happens...)
If I remove the β character from Title field it works just fine. If I create the list item manually through the SP web interface it works just fine, so I know that it is not that the character is invalid, just the creation of the list item through the API.
The headers for the post are:
var outHeaders = {
"Content-Type": "application/json;odata=verbose",
"Accept": "application/json;odata=verbose",
"Authorization": 'Bearer ' + token,
"Content-Length": data.length,
"X-RequestDigest": digest,
"IF-MATCH" : "*"
}
The data being posted is as follows
{
"__metadata": {
"type": "SP.Data.EmailArchiveListItem"
},
"Title": "TEST fail email β",
"Sender": "Mark Roden",
"Recipient": "Mark Roden",
"Body": "HI Marky"
}
The error returned is:
400
Bad Request
{
"error": {
"code": "-1, Microsoft.SharePoint.Client.InvalidClientQueryException",
"message": {
"lang": "en-US",
"value": "Invalid JSON. Unexpected end of input was found in JSON content. Not all object and array scopes were closed."
}
}
}
Any input/thoughts appreciated.
Try using this code: β That should make it through.
In 2021 (five years later) I had a similar problem (using the SharePoint MS Graph REST API) which I fixed by specifying the charset in the content-type explicitly:
application/json; charset=utf-8
Joe Jorden's answer at least got me this far - If you post the β or — into an RTF Field it works - posting it into a plain text field does not.