Is there a difference between authentication as a use case and an actor that has that privilege?

The first UML diagram features a basic user interacting with an E-Commerce site, where authentication is explicitly included for actions like placing orders, adding to the cart, and checking out.

In the second diagram, I've streamlined the authentication process by introducing an "Authenticated User" actor. This eliminates the need for explicit authentication in each specific use case.

I want to know if this is possible and which process you recommend following.

I know that authentication isn't a use case, but I haven't found a specific example to make this comparison.

I asked my professors and they said that only the first diagram is applicable. Also i did some researches in the internet.

Authenticate is not a use-case

First of all, authenticate is not really a use-case. It's like login. You already know it, but I'll clarify for the readers of this answer:

• From the use-case analysis point of view, it's not a goal for the user. No user would buy a system just to authenticate. It's just a constraint necessary for certain behaviours to complete.

• From the strict UML point of view, a use-case

  specifies a set of behaviors performed by that subject, which yields an observable result that is of value for Actors or other stakeholders

  But performing authentication may not necessarily be observable (for example if the authentication is performed via single sign on capability behind the scene) and the user may not value the result of the authentication on its own, but only the value of the other use cases for which authentication is a constraint. Of course there is some room of interpretation here.

• There is no order defined for use-cases. Use cases are not meant to describe workflow, whereas both of your diagrams expect an order.

Last but not least, more and more, authentication is no longer performed in the system but provided by an external system that is an identity provider. In this case, it may happens behind the scene without the user even knowing - one proof more that it's not a set of behavior performed in interaction with the user ;-) .

What diagram alternative is more suitable

I strongly disagree with your professor: the first alternative is not the recommended one, because it's a functional decomposition of your use-cases. While this is not forbidden in UML, it is seen as bad practice by leading authors such as Bittner & Spence.

The second one is more elegant in this regard, as your actor specialisation (which is fully legit) allows to see what an authenticated user can do and what a non-authenticated user can do. The only flaw is the authenticate use-case. But if you'd remove it, it would still be correct and express your design intention. How the authentication is managed, is then a technical or a user-interface detail.

Some side-remarks:

• if you'd insist on keeping authenticate, then add at least an association with User
• you do not need the redundant association between navigate products and Authenticated user, because this association is inherited from User (all what a user can do, the authenticated user can do as well)
• you should remove the arrows from the associations between actors and use-cases. This old notation is no longer valid (even if you'll find many examples of it on the internet and in books, refers to the UML 2.5.1 specifications in case of doubt).

A better way?

Use your second, diagram, but remove the authenticate use-case which is not one.

The authentication should either be a constraint, or some action to be performed (perhaps conditionally, e.g. if user is already authenticated). This action would be a part of the activity diagram that describes the details behind a use-case.

Even better: simplify further, because there are only two real goals here : Navigate products and Buy products The add to cart, place order, checkout are process steps or user interface details.