JWT(Json Web Token) is a token format. It is digitally-signed, self-contained, and compact. It provides a convenient mechanism for transferring data. JWT is not inherently secure, but the use of JWT can ensure the authenticity of the message so long as the signature is verified and the integrity of the payload can be guaranteed. JWT is often used for stateless authentication in simple use cases involving non-complex systems.
\nOAuth2 is an authorization protocol that builds upon the original OAuth protocol created in 2006, arising out of a need for authorization flows serving different kinds of applications from web and mobile apps to IoT. OAuth2 specifies the flows and standards under which authorization token exchanges should occur. OAuth2 does not encompass authentication, only authorization. For more information on OAuth2, please see IETF
\nJWT and OAuth2 are entirely different and serve different purposes, but they are compatible and can be used together. The OAuth2 protocol does not specify the format of the tokens, therefore JWTs can be incorporated into the usage of OAuth2.
\nFor example, the access_token returned from the OAuth2 Authorization Server could be a JWT carrying additional information in the payload. This could potentially increase performance by reducing round trips for the required information between the Resource Server and the Authorization Server. This is a good use case for incorporating JWT into OAuth2 implementations when transparent tokens are acceptable - there are scenarios requiring token opacity where this is not optimal.
\nAnother common way to use JWT in conjunction with OAuth2 is to issue two tokens: a reference token as access_token, and a JWT containing identity information in addition to that access token. In use cases where this implementation seems necessary, it is probably worth looking into OpenID Connect - an extension built upon OAuth2 and provides additional standardizations, including having an access_token and an id_token.
\nA common misconception is that using JWT with OAuth2 increases the security of an application, this is not true. As mentioned earlier, JWT is not an inherently secure mechanism, and the security of OAuth2 is upheld through the definitions of the actors involved in the authorization process and the specific steps to be taken for this process in different use cases. Security concerns regarding OAuth2 are best addressed by choosing the appropriate OAuth2 grant flow for the application based on use case, not the token format.
\nThe advantages of using JWT in addition to OAuth2 is in increased performance and decreased process complexity when it comes to certain flows; however, this may increase development complexity. When deciding whether to use JWT on top of OAuth2, it is best to begin by considering whether the performance gain is meaningful to your application, and whether that is worth the additional work required for development.
\n","frontmatter":{"date":"March 11, 2019","updated_date":null,"description":"Learn how to use JWT with OAuth and when & why","title":"How to Use JWT with OAuth","tags":["JWT","Oauth","JSON Web Token"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/d14806f1306c0379a98cfb3b3feceac2/14b42/photo-1454165804606-c3d57bc86b40.jpg","srcSet":"/static/d14806f1306c0379a98cfb3b3feceac2/f836f/photo-1454165804606-c3d57bc86b40.jpg 200w,\n/static/d14806f1306c0379a98cfb3b3feceac2/2244e/photo-1454165804606-c3d57bc86b40.jpg 400w,\n/static/d14806f1306c0379a98cfb3b3feceac2/14b42/photo-1454165804606-c3d57bc86b40.jpg 800w,\n/static/d14806f1306c0379a98cfb3b3feceac2/47498/photo-1454165804606-c3d57bc86b40.jpg 1200w,\n/static/d14806f1306c0379a98cfb3b3feceac2/724e2/photo-1454165804606-c3d57bc86b40.jpg 1350w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Ti Zhang","github":null,"avatar":null}}}},{"node":{"excerpt":"What is an SSL Certificate? Let’s start with some working definitions of the HTTP and HTTPS protocols. HTTP is the Internet protocol over…","fields":{"slug":"/engineering/lets-encrypt-with-ssl-certificates/"},"html":"What is an SSL Certificate?
\nLet’s start with some working definitions of the HTTP and HTTPS protocols. HTTP is the Internet protocol over which data is sent between a browser and a server when they are communicating. HTTPS is the secure counterpart of HTTP , which encrypts data to ensure private communication.1 An SSL certificate is a data file that is installed on a web server to enable the use of the HTTPS protocol.2
\nWhy SSL Certificates?
\nThe communication privacy that HTTP provides is desirable for obvious reasons: for example, you would not want a website you are purchasing something from to not encrypt your credit card information before sending it to the server, for that would expose it to everyone who needs only a decent understanding of how the internet works to access it. Other benefits of SSL certificates include:
\nConsiderations
\nThere are some considerations to be aware of when implementing SSL certificates on your server. There is a cost involved due to he infrastructure that has been put into place by the SSL certificate provider to issue the certificate. Additionally, processing encrypted data takes more server resources. However, there is available hardware that can minimize this impact.3 Considering the additional security and end user trust SSL certificates can bring to your website, there is no doubt that its benefits far outweigh the costs and efforts of its implementation.
\nA Final Note
\nYou might be aware that version 3.0 of the Secure Sockets Layer protocol was deprecated in 2015 by the IETF because of its vulnerabilities. Other protocols, such as TLS, are more secure and have to be used in replacement of SSL.5 This might lead you to think, how do I replace my SSL certificate with a TLS certificate so I ensure security in my website? The answer is you do not have to. Although the phrases ‘SSL certificate’ or ‘SSL/TLS certificates’ are used, the certificates are not bound to the protocol your server uses. Certificates can be used with either SSL or TLS; what determines what protocol you use is your server configuration.6
\nReferences:
\nNote: image labeled for reuse, taken from Google images.
\n","frontmatter":{"date":"January 14, 2019","updated_date":null,"description":null,"title":"Let's Encrypt with SSL Certificates","tags":["SSL","SSL Certificate","Security"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1,"src":"/static/0a5fe6d5d73fe4e13e3e6b415bb2983d/46604/ssl.png","srcSet":"/static/0a5fe6d5d73fe4e13e3e6b415bb2983d/69585/ssl.png 200w,\n/static/0a5fe6d5d73fe4e13e3e6b415bb2983d/497c6/ssl.png 400w,\n/static/0a5fe6d5d73fe4e13e3e6b415bb2983d/46604/ssl.png 500w","sizes":"(max-width: 500px) 100vw, 500px"}}},"author":{"id":"Ruben Gonzalez","github":"rubenprograms","avatar":null}}}},{"node":{"excerpt":"Both encryption and hashing have significant uses in cryptology and other fields. One defining difference between them is that encryption is…","fields":{"slug":"/engineering/encryption-and-hashing/"},"html":"Both encryption and hashing have significant uses in cryptology and other fields. One defining difference between them is that encryption is reversible, while hashing is irreversible. Because of this, encryption is often used for protecting the confidentiality of data. Only authorized people with the key should be able to access the data. On the other hand, hashing works well for verification; knowing the actual data is unnecessary, just whether or not the hashes are the same.
\nEncryption example: sending confidential documents to a co-worker through email.
\nHashing example: verifying user credentials for login.
\nEncryption is defined as conversion of electronic data into unreadable format by using encryption algorithms. This process of encoding the original data is called encryption. The data dump after encoding is called ciphertext.
\nThe purpose of encryption is to protect stored data, by guaranteeing that the information cannot be understood by individuals other than the proposed recipient(s).
\nEncryption transforms information under another format such that just particular individual(s) could decrypt the conversion.
\nThe Data Encryption Standard (DES) is a symmetric key algorithm that was widely used for many years. DES is a block cipher that uses a 64-bit block of plaintext and a 56-bit key in order to output a 64-bit block of ciphertext. The core of the algorithm is composed of a series of repetitive modules that transform the block of plaintext. Each module’s bit manipulation includes transposition, splitting, concatenation, and combination with the key. A security limitation is that the key can be brute forced, especially since in DES the key is a relatively short 56-bits (thus, 256possibilities). Because of the technological advances in computing, DES is now considered insecure.
\nTriple Data Encryption Standard (3DES/TDES) is a successor to DES, and runs the DES algorithm three times to each block of data. The standard keying option is to use 3 keys of 56-bits each, resulting in a final key of 3 x 56 = 168-bits. A security limitation is its vulnerability to meet-in-the-middle attacks, where essentially the attacker brute forces the encryption of the plaintext and decryption of the ciphertext at the same time. This allows the 168-bit key to be brute forced in 22 x 56iterations.
\nThe Advanced Encryption Standard (AES) is a symmetric key algorithm trusted worldwide including the U.S government with classified material. AES is a block cipher which uses 128-bit blocks of plaintext, and three key options: 128-bit, 192-bit, and 256-bit. On a high-level, AES shares many fundamental concepts with DES; in particular, transforming a block of plaintext through repetition and bit manipulation. This include substitution, transposition, and bitwise operations. Currently, the only security limitation is its theoretical risk to brute force.
\nThe Rivest-Shamir-Adleman (RSA) is a asymmetric key algorithm based on the difficulty of prime factorization. The algorithm first generates a private and public key using 2 random, sufficiently large, and distinct prime numbers. Public keys can then be distributed to external parties. Plaintext encrypted using the public key and RSA formula can only be decrypted using the private key. Security limitations include weak key generation due to poor choices in prime numbers, and the possibility of breakthroughs such as quantum computers trivializing prime factorization.
\nBlowfish is a symmetric key algorithm freely available in the public domain. As a block cipher, Blowfish processes 64-bit blocks of plaintext, and a key ranging from 32 to 448-bits. It is known to be fast compared to existing alternatives, except when changing keys. The algorithm involves multiple cycles of splitting the key into 2 subarrays, substituting bits, and performing a series of bitwise operations with parts of the plaintext block. A security limitation is its relatively small block size of 64-bits makes it vulnerable to birthday attacks, which is based on probability theory.
\nTwofish is a symmetric key algorithm freely available in the public domain. Twofish is a block cipher with 128-bit blocks of plaintext, and up to a 256-bit key. The designer of Blowfish also worked on Twofish. Similar to Blowfish, Twofish is a fast cipher, and shares some of the same concepts and structure in transforming a block of plaintext. Currently, the only security limitation is its theoretical risk to brute force.
\nSkipjack is a symmetric key algorithm with 64-bit blocks of plaintext and 80-bit key. It was designed by the NSA with the purpose of encrypting voice transmission, and later declassified for public knowledge. The algorithm is based off a technique of repeatedly splitting the plaintext block and performing bitwise operations with subkeys. Currently, the only security limitation is its theoretical risk to brute force, especially due to its relatively short key.
\nSymmetric key encryption
\nAsymmetric key encryption
\nHashing is a process of taking a big block of data and reducing it to smaller blocks of data in a specific order by using hashing functions. Cryptographic hashes are irreversible.
\nSome properties of hashed data:
\nThe output of a hashing algorithm is a hashed value, also known as a message digest. Analogous to a fingerprint.
\nThe Message Digest 4 (MD4) algorithm takes an input text of arbitrary length, and outputs a 128-bit digest in the form of a 32-digit hexadecimal number. The algorithm works by first padding the text to a certain length, and then appending to it a 64-bit binary representation of the text. Next, the text is processed in blocks of 512-bits, with each block undergoing three rounds of bit manipulation. MD4 is insecure, as a collision attack was found. This is where two input texts produce the same output digest (a hash collision), thus allowing for issues such as forging digital signatures.
\nThe Message Digest 5 (MD5) algorithm is similar to MD4, except each block is processed in four more complex rounds. MD5 is also considered insecure, as a collision attack was found. However, MD5 is still often used in the industry for cases which do not require collision resistance, such as password hashing. Better solutions exists, but tradition and lack of modern security expertise drives the popularity of MD5.
\nThe Secure Hash Algorithm 1 (SHA-1) takes an input text of arbitrary length, and outputs a 160-bit digest, typically in the form of a 40-digit hexadecimal number. The algorithm performs padding, and 80 rounds of text manipulation such as bitwise shifting and XOR operations. SHA-1 is considered insecure, as a collision attack was found.
\nThe Secure Hash Algorithm 2 (SHA-2) is a family of successors to SHA-1. This includes SHA-224, SHA-256, SHA-384, and SHA-512. Digest sizes range from 224 to 512-bits, increasing its difficulty to brute force. The algorithm consists of padding, and 64 or 80 rounds of bit manipulation. A security limitation is its vulnerability to length extension attacks. When the algorithm is finished, this attack takes advantage of the internal state of the machine in order to keep processing new text. As a result, it is possible to construct a new digest which is an extension of the original digest.
\nHash-based Message Authentication Code SHA-1 (HMAC-SHA1) uses the SHA-1 hashing algorithm and a key in order to generate a HMAC. Due to the usage of a key, there is less chance of a hash collision, but the key is vulnerable to discovery through brute force. Additionally, HMAC is vulnerable to length extension attacks.
\nHash-based Message Authentication Code SHA-256 (HMAC-SHA256) uses the SHA-256 hashing algorithm and a key in order to generate a HMAC. Security concerns include the key being brute forced, and length extension attacks.
\nPassword-Based Key Derivation Function 2 (PBKDF2) is a hashing algorithm designed to be used for passwords. By design, hashing using PBKDF2 is slow, making it much more difficult to brute force a password. This is because the algorithm takes in a random salt, as well as the desired number of times to hash the password. Other inputs include the desired length of the output, and the hashing function used. Typically, the recommended number of iterations range in the tens of thousands, but depends on the hashing function and capabilities of the application. However, brute force still remains a threat, especially with weakly chosen salts and a small number of iterations.
\nArgon2 is a cryptographic hashing algorithm, most recommended for password hashing. It hashes a plain text input to a hash as per the parameters mentioned. It is governed by six parameters: password, salt, memory cost, time cost, parallelism factor, the hash length, along with one of the three algorithms included in it.
\nArgon2 has 3 versions: Argon2d, Argon2i and Argon2id.
\nIt has experienced two attacks on Argon2i. The first attack is applicable only to the old version of Argon2i. The second attack has not been secured yet.
\nAuthentication
\nMessage integrity
\nIdentification
\nThe process of transforming the data by using an algorithm (that is publicly available) into another format.
\nThe motivation behind encoding is to change information with the goal that it can be appropriately (and securely) fed to a different system. The main objective is not to keep data secret, but instead to guarantee that it is ready to be legitimately used.
\nThe process of using the same key for encrypting and decrypting the text is called symmetric key cryptography.
\nThe process of using a public key for encryption and a private key for decryption is called asymmetric key cryptography.
\nThe process of encrypting or decrypting the text bit by bit using a symmetric key is called stream cipher. The stream cipher process is high speed and requires low hardware complexity.
\nThe process of encrypting or decrypting the text block by block using a symmetric key is called block cipher. Block ciphers are the functions that take an input message and a key in order to create a new, encrypted ciphertext. Block cipher are used with Symmetric key encryption.
\nBlock ciphers are invertible and efficiently computable. E.g. DES, AES, BlowFish etc.
\nSalts are an additional piece of data used in hashing algorithms, typically for passwords. They help protect against brute force attacks, by adding complexity to the hashes. As a result, salts increase the time taken to brute force a single hash, and deter against optimizations such as dictionaries and precomputed tables.
\n","frontmatter":{"date":"December 24, 2018","updated_date":null,"description":null,"title":"Encryption and Hashing","tags":["Encryption","Hashing"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":3.278688524590164,"src":"/static/9f60d8a12e2cb9240bfe54b54515b42a/3087f/encryption-and-hashing.png","srcSet":"/static/9f60d8a12e2cb9240bfe54b54515b42a/69585/encryption-and-hashing.png 200w,\n/static/9f60d8a12e2cb9240bfe54b54515b42a/497c6/encryption-and-hashing.png 400w,\n/static/9f60d8a12e2cb9240bfe54b54515b42a/3087f/encryption-and-hashing.png 615w","sizes":"(max-width: 615px) 100vw, 615px"}}},"author":{"id":"Andy Yeung","github":null,"avatar":null}}}},{"node":{"excerpt":"A JSON Web Token (JWT) is a JSON object that is defined in RFC 7519 as a safe way of transmitting information between two parties…","fields":{"slug":"/engineering/jwt/"},"html":"A JSON Web Token (JWT) is a JSON object that is defined in RFC 7519 as a safe way of transmitting information between two parties. Information in the JWT is digitally-signed, so that it can be verified and trusted.
\nJWT Properties
\nJWT Use Cases
\nJWT contains three parts: Header, Payload, and Signature which are separated by a dot.
\nHeader.Payload.Signature
Header
\nThe JWT Header consists of 2 parts:
\n{ \n "typ" : "JWT", \n "alg" : "HS256" \n}Header Algorithm Types:
\nalg Value
\nDigital Signature or MAC Algorithm
\n| Algo | \nDescription | \n
|---|---|
| HS256 | \nHMAC using SHA-256 hash algorithm | \n
| HS384 | \nHMAC using SHA-384 hash algorithm | \n
| HS512 | \nHMAC using SHA-512 hash algorithm | \n
| RS256 | \nRSASSA using SHA-256 hash algorithm | \n
| RS384 | \nRSASSA using SHA-384 hash algorithm | \n
| RS512 | \nRSASSA using SHA-512 hash algorithm | \n
| ES256 | \nECDSA using P-256 curve and SHA-256 hash algorithm | \n
| ES384 | \nECDSA using P-384 curve and SHA-384 hash algorithm | \n
| ES512 | \nECDSA using P-521 curve and SHA-512 hash algorithm | \n
The Base64Url-encoded Header, which is first part of our JWT, looks like the following:
\neyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
Payload
\nThe Payload, also known as the JWT claim, contains all of the information we want to transmit.
\nDifferent types of claims can be used to build the Payload:
\n| Code | \nName | \nDescription | \n
|---|---|---|
| iss | \nissuer | \nIdentifies the principal that issued the JWT. | \n
| sub | \nsubject | \nIdentifies the principal that is the subject of the JWT. | \n
| aud | \naudience | \nIdentifies the recipients that the JWT is intended for. | \n
| exp | \nExpiration time | \nIdentifies the expiration time on or after which the JWT MUST NOT be accepted for processing. | \n
| nbf | \nNot before | \nIdentifies the time before which the JWT MUST NOT be accepted for processing. | \n
| iat | \nIssue at | \nIdentifies the time at which the JWT was issued. | \n
| jti | \nJWT id | \nUnique identifier for the JWT, can be used to prevent the JWT from being replayed. | \n
Example Payload:
\n{ \n "sub": "1234567890", \n "name": "Frank Emic", \n "jti": "4b5fcea6-2a5e-4a9d-97f2-3d8631ea2c5a", \n "iat": 1521191902, \n "exp": 1521195630 \n}This example contains a combination of registered and public claims. “sub”,”jti”,”iat”, and “exp” are registered claims and “name” is a public claim.
\nThe Base64Url-encoded Payload, which is the second part of our JWT, looks like the following:
\neyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkZyYW5rIEVtaWMiL \nCJqdGkiOiI0YjVmY2VhNi0yYTVlLTRhOWQtOTdmMi0zZDg2MzFlYTJjNWEiLCJpYXQiOjE1MjExOTE5MDIsImV4cCI6MTUyMTE5NTYzMH0Signature
\nThe final part of our JWT is the Signature. To create the Signature, we need 3 components:
\nvar encodedString = base64UrlEncode(header) + \".\" + base64UrlEncode(payload);
\nHMACSHA256(encodedString, 'secret');
The secret is the Signature held by the server in order to verify tokens and sign new ones.
\nThe above Base64Url-encoded Header and Payload are combined with a dot, and then digitally-signed using the secret. This generates the Signature as the third part of the our JWT:
\nwGDoDSxfKj3Ns379NVxocwM9TOiwxhxWl
\nPutting It All Together
\neyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkZyYW5rIEVtaWMiL \nCJqdGkiOiI0YjVmY2VhNi0yYTVlLTRhOWQtOTdmMi0zZDg2MzFlYTJjNWEiLCJpYXQiOjE1MjExOTE5MDIsImV4cCI6MTUyMTE5NTYzMH0.wGDoDSxfKj3Ns379NVxocwM9TOiwxhxWlThis is our final JWT, containing the Header, Payload, and Signature joined together with dots. It can be passed as a URL parameter, a POST parameter, or in the HTTP header to authenticate or exchange information.
\nYou can play around with JWT using our JWT SSO Tool.
\nNote: JWT does not hide information; it just encodes information using the digitally-signed signature and verifies that the information has not been altered over the network. So, do not add any sensitive information in the JWT claim.
\nConclusion
\nJWT comprises three encoded parts: Header, Payload, and Signature. It can be passed as a URL or POST parameter, or in an HTTP header. Due to JWT's lightweight, self-containing, and versatile strucutre, it remains a popular tool for information exchange and authentication.
\n","frontmatter":{"date":"July 11, 2018","updated_date":null,"description":null,"title":"What is JSON Web Token","tags":["JWT","JSON Web Token"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.7699115044247788,"src":"/static/280ee8f1345faeaa2d33899ee2475b0b/ee604/jwt.png","srcSet":"/static/280ee8f1345faeaa2d33899ee2475b0b/69585/jwt.png 200w,\n/static/280ee8f1345faeaa2d33899ee2475b0b/497c6/jwt.png 400w,\n/static/280ee8f1345faeaa2d33899ee2475b0b/ee604/jwt.png 800w,\n/static/280ee8f1345faeaa2d33899ee2475b0b/f3583/jwt.png 1200w,\n/static/280ee8f1345faeaa2d33899ee2475b0b/e4d72/jwt.png 1280w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Mayank Agarwal","github":"mayankagrwal","avatar":null}}}},{"node":{"excerpt":"Nowadays, many API providers support JSONP requests. One reason for this is that most web browsers disable cross-domain requests when using…","fields":{"slug":"/engineering/understanding-jsonp/"},"html":"Nowadays, many API providers support JSONP requests. One reason for this is that most web browsers disable cross-domain requests when using basic Ajax.
\nFor example, if your website has the domain \"a.com\", it will use JavaScript hosted on a.com. When the a.com JavaScript makes an Ajax call to make a request on b.com, most web browsers would automatically deem the Ajax call as insecure and disable it. This is called the Same-Origin Policy and web browsers have this to prevent malicious scripts from sending off information to a different domain. Because you need the a.com JavaScript to access b.com to provide your service, this seems to pose a pretty big issue … JSONP to the rescue!
\nBefore understanding JSONP, we already know JSON is an object notation of JavaScript. The \"P\" stands for padding. So it’s a padded JSON, and, to be more specific, the JSON object is padded with a JavaScript function! It looks like this:
\njsFunction({"name" : "Ash Ketchum", "role" : "Pokemon trainer"});Thus, technically, any call that retrieves JSONP, sends off an executable JavaScript line, if and only if your page has a JavaScript function that has the same function name that’s returned in the JSONP!
\nLet’s look at an example: say the user is on a.com and the browser is using JavaScript hosted on a.com. Then I shouldn't have any issues making Ajax calls to a.com. Ajax GET requests to b.com however, would fail. To avoid this, I first create a method in the JavaScript code that's located on a.com with the following signature
\nfunction getData(data){\n// use this data\n}With this, an Ajax call using JSONP will pass through fine and return this data:
\ngetData({"name" : "test", "value" : "test Value"});After processing the request, the web browser will call the \"getData\" function because whenever a JavaScript tag is loaded, it gets executed.
\nNow, the JSON object will get passed as an argument to the getData function as the data parameter. So, you can think of the getData as a callback method of the request.
\nYou can see the below code clearly
\nfunction addJavascriptFile = function (url, context) {\ncontext = context || document;\nvar head = context.getElementsByTagName('head')\\[0\\];\nvar js = context.createElement('script');\njs.src = url;\njs.type = "text/JavaScript";\nhead.appendChild(js);\nreturn js;\n}\n\nfunction getJsonp = function (url, handle) {\n\n//creating random name of function as to not conflict with others\nvar func = 'jsonpCallback' + Math.floor((Math.random() \\* 1000000000000000000) + 1);\n\n//adding randomly created function to global window object\nwindow\\[func\\] = function (data) {\n\n//calling handle\nhandle(data);\n\n//removing random named declared function\nwindow\\[func\\] = function () {};\n\n//removing added js\ndocument.head.removeChild(js);\n}\n\n//manipulating and adding js file to head\nvar endurl = url.indexOf('?') != -1 ? url + '&callback=' + func : url + '?callback=' + func;\nvar js = addJavascriptFile(endurl);\n}The above code is not doing any magic, it will accept the URL of the API and add a parameter callback with a random name, and also create a global method with this same random name. It will then create a script tag and add the complete URL to src of this tag.
\nThe API will read the callback parameter from the query string and, if the callback parameter has the value \"jsonCallback\", the response will be as follows:
\njsonpCallback({"name" : "test", "value" : "test Value"});NuGet is a free and open-source package manager for the .NET ecosystem. We can create and install packages using NuGet client tools. All of the .NET packages are hosted for publishing and consumption on a central package repository known as NuGet Gallery.
\nPrerequisites
\nCreate a class library project
\nFor a .NET package to be published in the NuGet Gallery, it should be a valid class library project. The following instructions can be used to create a simple class library project:
\nFor a real useful NuGet package, you should write necessary code which can be used by others to develop applications. However, a class library from the template is sufficient to create a package.
\nConfigure Package Properties
\nRun the pack command
\nAcquire API Key
\nImportant: Save your key in a secure location because you cannot copy the key again later on. If you return to the API key page, you need to regenerate the key to copy it.
\nPublish with nuget push
\nRun the following command, specifying your package name and replacing the key value with your API key:
\nnuget push <PACKAGE-NAME>.nupkg <API-KEY> -Source https://api.nuget.org/v3/index.jsonManage the published package
\nYou can view your published package in your profile on nuget.org. Select Manage Packages to see the one that was just published. It might take a while for your package to be visible in search results.
\nIf you want to unlist the package and hide it from search results, follow the steps listed below:
\nGoogle has prepared a roadmap to restrict third-party cookies in Chrome. Since 04 January 2024, Chrome has rolled out third-party cookie restrictions for 1% of stable clients and 20% of Canary, Dev, and Beta clients.
\nWhat does it mean for user authentication?
\nOn one hand, Google believes third-party cookies are widely used for cross-site tracking, greatly affecting user privacy. Hence, Google wants to phase out (or restrict) supporting third-party cookies in Chrome by early Q2 2025 (subject to regulatory processes).
\nOn the other hand, Google introduced Privacy Sandbox to support the use cases (other than cross-site tracking and advertising) previously implemented using third-party cookies.
\nIn this article, we’ll discuss:
\nThird-party cookie restrictions affect user authentication in three ways, as follows.
\nIf your website or app uses an external Identity Provider (IdP) — like LoginRadius, the IdP sets a third-party cookie when the user authenticates on your app.
\nIf you have multiple apps across domains within your organization and authentication is handled using an IdP (internal or external) with web SSO, you already use third-party cookies to facilitate seamless access for each user using a single set of credentials.
\nIf you have implemented web SSO with one primary domain and multiple sub-domains of the primary domain, third-party cookie restrictions may not apply. For now, Google doesn’t consider the cookies set by sub-domains as third-party cookies, although this stance may change in the future.
\nFor example, you have apps at example.com, travel.example.com, stay.example.com, and web SSO is handled by auth.example.com. In this case, third-party cookie restrictions don’t apply.
Federated SSO is similar to, albeit different from, web SSO. It can handle multiple IdPs and applications—aka., Service Providers (SPs)—spanning multiple organizations. It can also implement authentication scenarios that are usually implemented through web SSO.
\nUsually, authentication is handled on a separate pop-up or page when the user wants to authenticate rather than on the application or website a user visits.
\nFor example, you already use federated SSO if you facilitate authentication for a set of apps through multiple social identity providers as well as traditional usernames and passwords.
\n\n\nNote: It is also possible to store tokens locally, not within cookies. In this case, third-party cookie restrictions won’t affect token-based authentication. However, the restrictions still affect authentication where tokens are stored within third-party cookies (a common and secure method).
\n
Google has been developing alternative features and capabilities for Chrome to replace third-party cookies as part of its Privacy Sandbox for Web initiative.
\nSpecific to authentication, Google recommends the following:
\nCHIPS are a restricted way of setting third-party cookies on a top-level site without making them accessible on other top-level sites. Thus, they limit cross-site tracking and enable specific cross-site functionalities, such as maps, chat, and payment embeds.
\nFor example, a user visits a.com with a map embed from map-example.com, which can set a partitioned cookie that is only accessible on a.com.
If the user visits b.com with a map embed from map-example.com, it cannot access the partitioned cookie set on a.com. It has to create a separate partitioned cookie specific to b.com, thus blocking cross-site tracking yet allowing limited cross-site functionality.
You should specifically opt for partitioned cookies (CHIPS), which are set with partitioned and secure cookie attributes.
\nIf you’re using an external identity provider for your application, CHIPS is a good option to supplant third-party cookie restrictions.
\nHowever, CHIPS may not be ideal if you have a web SSO or federated SSO implementation. It creates separate partitioned cookies for each application with a separate domain, which can increase complexity and create compatibility issues.
\nWith Storage Access API, you can access the local storage in a third-party context through iframes, similar to when users visit it as a top-level site in a first-party context. That is, it gives access to unpartitioned cookies and storage.
\nStorage Access API requires explicit user approval to grant access, similar to locations, camera, and microphone permissions. If the user denies access, unpartitioned cookies and storage won’t be accessible in a third-party context.
\nIt is most suitable when loading cross-site resources and interactions, such as:
\nVerifying user sessions when allowing interactions on an embedded social post or providing personalization for an embedded video.\nEmbedded documents requiring user verification status to be accessible.
\nAs it requires explicit user approval, it is advisable to use Storage Access API when you can’t implement an identity use case with the other options.
\nWith Related Website Sets, you can declare a primary website and associatedSites for limited purposes to grant third-party cookie access and local storage for a limited number of sites.
Chrome automatically recognizes related website sets declared, accepted, and maintained in this open-source GitHub repository: Related Website Sets
\nIt provides access through Storage Access API directly without prompting for user approval, but only after the user interacts with the relevant iframe.
\nIt is important to declare a limited number of domains in related website sets that are meaningful and used for specific purposes. Google may block or suspend any exploitative use of this feature.
\nThe top-level site can also request approval for specific cross-site resources and scripts to Storage Access API using resuestStorageAccessFor() API.
If you’re using an external identity provider for your web application, you can declare the domain of the identity provider in the related set to ensure limited third-party cookies and storage access to the identity provider, thus ensuring seamless user authentication.
\nRelated Website Sets can also work to supplement third-party cookie restrictions in web SSO and federated SSO if the number of web applications (or domains) is limited.
\nFedCM API enables federated SSO without third-party cookies.
\nWith FedCM API, a user follows these steps for authentication:
\nYou can access a user demo of FedCM here: FedCM.
\nFor more information about implementing federated SSO with FedCM API, go through the FedCM developer guide.
\nFirstly, we’re committed to solving our customers' user identity pain points — and preparing for the third-party cookies phase-out is no different.
\nWe’ll implement the most relevant and widely useful solutions to facilitate a smooth transition for our customers.
\nPlease subscribe to our blog for more information. We’ll update you on how we help with the third-party cookie phase-out.
\nThe proposed changes to phase out third-party cookies and suggested alternatives are evolving as Google has been actively collaborating and discussing changes with the border community.
\nMoreover, browsers like Firefox, Safari, and Edge may approach restricting third-party cookies differently than Google does.
\nFrom LoginRadius, we’ll keep you updated on what we’re doing as a leading Customer Identity and Access Management (CIAM) vendor to prepare for the third-party cookie phase-out.
\nTop-level site: It is the primary site a user has visited.
\nFirst-party cookie: A cookie set by the top-level site.
\nThird-party cookie: A cookie set by a domain other than the top-level site. For example, let’s assume that a user has visited a.com, which might use an embed from loginradius.com to facilitate authentication. If loginradius.com sets a cookie when the user visits a.com, it is called a third-party cookie as the user hasn’t directly visited loginradius.com.