blog

commit

1a265de64e4e3c401a0b3237689f0460532dbfd0

parent

a019ed45d9adcf70bdfd65911acf3cdf8d1be129

Author

Tobias Bengfort <tobias.bengfort@posteo.de>

Date

2025-04-27 08:47

typos

Diffstat

2 files changed, 5 insertions, 5 deletions

diff --git a/_content/posts/2024-03-15-fluid-typography/index.md b/_content/posts/2024-03-15-fluid-typography/index.md

@@ -219,7 +219,7 @@ dependencies. And I am not yet sure this will happen anytime soon.
  219   219 -	[Container queries][container-queries] and the `cqi` unit could be useful to
  220   220 	apply these techniques to individual components.
  221   221 
  222    -1 -	Vertical rhythm is a very different approach to typography then what I
   -1   222 -	Vertical rhythm is a very different approach to typography than what I
  223   223 	described here: Instead of adjusting the line height to the font size, you
  224   224 	start with a fixed line grid and fit the elements in there. That is
  225   225 	especially useful for newspaper-style layouts where you want the lines in

diff --git a/_content/posts/2025-01-07-oidc/index.md b/_content/posts/2025-01-07-oidc/index.md

@@ -155,7 +155,7 @@ In reality, OpenID Connect has some additional steps:
  155   155     -   check that "iss" matches the "issuer" from step 1
  156   156     -   check that the token has been issued in the past (`iat`) and that it
  157   157         has not yet expired (`exp`).
  158    -1     -   check that this token was created for this client (`aud`)
   -1   158     -   check that this token was created for this application (`aud`)
  159   159     -   check that the nonce matches the one that was sent in step 2
  160   160 
  161   161 7.  Finally, the application fetches the user information from the userinfo
@@ -222,7 +222,7 @@ Even though some options have been removed, there are still plenty left. For
  222   222 example, there are at least two ways to pass user information to applications
  223   223 (none of which match my expectation): It can be included in the ID token or
  224   224 received from a separate userinfo endpoint. I have seen both in the wild.
  225    -1 Realistically, SSO services need do both to be compatible.
   -1   225 Realistically, SSO providers need do both to be compatible.
  226   226 
  227   227 ## Terminology
  228   228 
@@ -240,7 +240,7 @@ really confusing.
  240   240 
  241   241 In non-SSO login, there are two main attack vectors: Either you manage to trick
  242   242 the login (e.g. by guessing the password) or you manage to steal a session
  243    -1 cookie. Both of these vectors are the exactly the same with SSO.
   -1   243 cookie. Both of these vectors are exactly the same with SSO.
  244   244 
  245   245 The benefits are that you only have a single login implementation, so you can
  246   246 focus on making that really robust. You also only expose the password to a
@@ -281,7 +281,7 @@ request).
  281   281 The differences between these parameters are small: `state` is checked in step
  282   282 4, so it can prevent making the token request. `code_challenge` is checked in
  283   283 step 5, so the token request is made, but the application does not receive
  284    -1 tokens. `nonce` is checked in step 6, at the very end.
   -1   284 tokens if the check fails. `nonce` is checked in step 6, at the very end.
  285   285 
  286   286 One benefit of `code_challenge` is that it is checked by the SSO provider, so
  287   287 by requiring it you can be sure that it is implemented correctly everywhere. Of