Add webauthn blogs #139
Add webauthn blogs #139
Conversation
|
PR created by lauravuo |
There was a problem hiding this comment.
This is a good but also a problematic picture. It's difficult to translate or understand because it's freestyle, i.e., no formal syntax or semantics. For example, are the arrows dependency-directions or something else?
Another thing that came to my mind is the native app part, how it can call the platform WebAuthn API. As we know, only with some help, like an in-app browser or something more complex.
Something else that came to my mind by looking at the picture was that would it be helpful to add a reference to our other authenticator-related stuff.
There was a problem hiding this comment.
Yes, it is hard to draw a picture that would describe the setup in simple enough level yet being technically correct. I am thinking that the target audience of this post is an average web application developer who is used to implement username-password-styled authentication mechanisms and describe in the text how this FIDO world differs from that (simple enough way). The purpose of the picture is not to give a full overview of how the different technologies interact with each other but to lay out the different bits and pieces relevant to the application developer. Maybe we could brainstorm together how this can be improved.
"Platform WebAuthn API" tries to describe the platform specific libraries that actually implements the dance with the authenticators and provide the user interface dialogs etc. I think I stole the term from a MS blog post, but most likely there is a more correct one.
Cross-referencing blogs is a good idea. I was planning to refer to the headless authenticator in my next post that handles the automated testing of the WebAuthn flow, but maybe there could be a suitable slot here as well, as long as it doesn't overcomplicate things 😄
| much more security and usability than passwords. These authentication methods utilize strong and | ||
| phishing-resistant public key credentials that the keys or authenticators, as we call them, | ||
| can create automatically. However, implementing passwordless support in your web application, | ||
| or even replacing passwords altogether, might initially seem overwhelming. |
There was a problem hiding this comment.
Here's a point of view about the last sentence: authentication should have always been a separate 'thing' or a service from the actual web app. If it's not, something has been wrong for a long time. Should it be as 'simple' as changing the authentication service? Is this especially not true with OIDC?
There was a problem hiding this comment.
"Overwhelming" term refers to the fact that if the passwordless technology is unfamiliar, and you have implemented an existing application with traditional username-password-based authentication, it might seem quite a big job to undertake implementing new routines for the credential handling, both in front-end and back-end side.
There was a problem hiding this comment.
"Overwhelming" term refers to the fact that if the passwordless technology is unfamiliar, and you have implemented an existing application with traditional username-password-based authentication, it might seem quite a big job to undertake implementing new routines for the credential handling, both in front-end and back-end side.
| application developers: we don't have to care about the dirty details of each | ||
| authenticator implementation. Our job is to take into use the platform or browser APIs | ||
| that enable the creation and use of the authenticator-managed credential. | ||
| The operating system or browser handles needed user interaction and shows standard dialogs when appropriate. |
There was a problem hiding this comment.
Does the operation system offer a FIDO2 API? This is something I found; it directs the terminology towards the passkey.
There was a problem hiding this comment.
I think this refers to the same question as "the platform WebAuthn API" in the picture above. Lets discuss online.
| {{< imgproc cover Fit "825x825" >}} | ||
| <em>The team implements passwordless support by integrating credential handling into | ||
| the client application and the backend authentication service. Client applications | ||
| can use the platform WebAuthn capabilities through the native APIs or browser JavaScript implementation. |
|
|
||
| Furthermore, we need to have a backend service in place that is capable of storing and verifying | ||
| these credentials so that the authentication can take place correctly. The service must support | ||
| [the W3C WebAuthn standard](https://www.w3.org/TR/webauthn/) so that the backend |
There was a problem hiding this comment.
I continue with the same subject: if the FIDO2 server supports only WebAuthn endpoints, connections from native apps aren't as simple as they first seemed to be -- as we know. Maybe that should be covered in the blog. That would lead to UAF.
There was a problem hiding this comment.
As far as I know, the native apps can use the same endpoints - at least this is how it worked with the Flutter app. I think sending and receiving data from the endpoint is not part of the API - that is left to the app developer, similarly as with the web application.
| Note right of Server: Validate data. <br/> Store the public key and the credential id, </br> and attach to user. | ||
| Server-->>Client: Registration OK! | ||
| ``` | ||
|
|
There was a problem hiding this comment.
I suggest adding some text here. It doesn't seem very easy to read the sequence diagrams when they are together. The first time, I thought they were one large scenario.
There was a problem hiding this comment.
Yes, I am doubting if those diagrams are needed at all, but would like to describe somehow in more details, what exactly needs to be done if one wishes to implement this from scratch 🤔
| Server-->>Client: Return credential request options. | ||
| Note left of Client: Get credential with received options. <br/> Create signature with the private key.<br/>navigator.credentials.get | ||
| Client->>Server: Send assertion to server.<br/>/assertion/result | ||
| Note right of Server: Validate data and verify signature. |
There was a problem hiding this comment.
These are good, but if the blog wants to boost FIDO2 here, we could mention authenticator cloning checks, user prense, etc.
There was a problem hiding this comment.
Yes, a good idea, but I don't want to go too deep into the technology pros and cons. That should/could be a topic of its own.
| to familiarize themselves with the new logic and concepts. In addition, | ||
| as there are strict security requirements, testing the authentication flows | ||
| in a local development environment might be challenging at times, as the client and server | ||
| need to belong to the same domain. The local testing environment is something that the team |
There was a problem hiding this comment.
... domain, or even more difficult, the plain HTTP works only for the localhost.
There was a problem hiding this comment.
Yes, and iOS brings yet another bunch of limitations: you need to have the associated domain.
| as there are strict security requirements, testing the authentication flows | ||
| in a local development environment might be challenging at times, as the client and server | ||
| need to belong to the same domain. The local testing environment is something that the team | ||
| should resolve and enable together already early in the project so that it will not become a bottleneck. |
There was a problem hiding this comment.
Should this chapter be split into a tips list?
| in a local development environment might be challenging at times, as the client and server | ||
| need to belong to the same domain. The local testing environment is something that the team | ||
| should resolve and enable together already early in the project so that it will not become a bottleneck. | ||
|
|
There was a problem hiding this comment.
I mentioned the architecture 'thing' earlier. As far as I understand web apps, I have always thought pros should handle authentication. That leads to preferring federated authentication or OIDC, at least. What kind of implications could the security (end decentralization) passkey have? Storing just public keys is far better than storing password hashes.
I just wanted to let you know that I leave it to you to think if you want to bring these things to the blog or if they are even relevant.
There was a problem hiding this comment.
Yes, it would be good to sum the technology pros but I am thinking this post already the next step: the reader has heard about this new passwordless technology, has understood the benefits and now wants to take it into use.
It is true that many apps do and should do the authentication in the way you mentioned, but in many applications the first implemented authentication method is username+password. Also, I think that it would be good to play around with this tech just to undestand the basics better.
Good comments, and they make me start to wonder if I should publish this at all 😄
|
PR created by lauravuo |
|
PR created by lauravuo |
|
Discussed online and make changes accordingly. Thanks for review @lainio |
No description provided.